mirror of
https://github.com/openssl/openssl.git
synced 2024-11-27 05:21:51 +08:00
215 lines
6.6 KiB
Plaintext
215 lines
6.6 KiB
Plaintext
=pod
|
|
|
|
=head1 NAME
|
|
|
|
SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options, SSL_get_options - manipulate SSL engine options
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
long SSL_CTX_set_options(SSL_CTX *ctx, long options);
|
|
long SSL_set_options(SSL *ssl, long options);
|
|
|
|
long SSL_CTX_get_options(SSL_CTX *ctx);
|
|
long SSL_get_options(SSL *ssl);
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
SSL_CTX_set_options() adds the options set via bitmask in B<options> to B<ctx>.
|
|
Options already set before are not cleared!
|
|
|
|
SSL_set_options() adds the options set via bitmask in B<options> to B<ssl>.
|
|
Options already set before are not cleared!
|
|
|
|
SSL_CTX_get_options() returns the options set for B<ctx>.
|
|
|
|
SSL_get_options() returns the options set for B<ssl>.
|
|
|
|
=head1 NOTES
|
|
|
|
The behaviour of the SSL library can be changed by setting several options.
|
|
The options are coded as bitmasks and can be combined by a logical B<or>
|
|
operation (|). Options can only be added but can never be reset.
|
|
|
|
SSL_CTX_set_options() and SSL_set_options() affect the (external)
|
|
protocol behaviour of the SSL library. The (internal) behaviour of
|
|
the API can be changed by using the similar
|
|
L<SSL_CTX_set_modes(3)|SSL_CTX_set_modes(3)> and SSL_set_modes() functions.
|
|
|
|
During a handshake, the option settings of the SSL object are used. When
|
|
a new SSL object is created from a context using SSL_new(), the current
|
|
option setting is copied. Changes to B<ctx> do not affect already created
|
|
SSL objects. SSL_clear() does not affect the settings.
|
|
|
|
The following B<bug workaround> options are available:
|
|
|
|
=over 4
|
|
|
|
=item SSL_OP_MICROSOFT_SESS_ID_BUG
|
|
|
|
www.microsoft.com - when talking SSLv2, if session-id reuse is
|
|
performed, the session-id passed back in the server-finished message
|
|
is different from the one decided upon.
|
|
|
|
=item SSL_OP_NETSCAPE_CHALLENGE_BUG
|
|
|
|
Netscape-Commerce/1.12, when talking SSLv2, accepts a 32 byte
|
|
challenge but then appears to only use 16 bytes when generating the
|
|
encryption keys. Using 16 bytes is ok but it should be ok to use 32.
|
|
According to the SSLv3 spec, one should use 32 bytes for the challenge
|
|
when operating in SSLv2/v3 compatibility mode, but as mentioned above,
|
|
this breaks this server so 16 bytes is the way to go.
|
|
|
|
=item SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG
|
|
|
|
ssl3.netscape.com:443, first a connection is established with RC4-MD5.
|
|
If it is then resumed, we end up using DES-CBC3-SHA. It should be
|
|
RC4-MD5 according to 7.6.1.3, 'cipher_suite'.
|
|
|
|
Netscape-Enterprise/2.01 (https://merchant.netscape.com) has this bug.
|
|
It only really shows up when connecting via SSLv2/v3 then reconnecting
|
|
via SSLv3. The cipher list changes....
|
|
|
|
NEW INFORMATION. Try connecting with a cipher list of just
|
|
DES-CBC-SHA:RC4-MD5. For some weird reason, each new connection uses
|
|
RC4-MD5, but a re-connect tries to use DES-CBC-SHA. So netscape, when
|
|
doing a re-connect, always takes the first cipher in the cipher list.
|
|
|
|
=item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG
|
|
|
|
...
|
|
|
|
=item SSL_OP_MICROSOFT_BIG_SSLV3_BUFFER
|
|
|
|
...
|
|
|
|
=item SSL_OP_MSIE_SSLV2_RSA_PADDING
|
|
|
|
...
|
|
|
|
=item SSL_OP_SSLEAY_080_CLIENT_DH_BUG
|
|
|
|
...
|
|
|
|
=item SSL_OP_TLS_D5_BUG
|
|
|
|
...
|
|
|
|
=item SSL_OP_TLS_BLOCK_PADDING_BUG
|
|
|
|
...
|
|
|
|
=item SSL_OP_ALL
|
|
|
|
All of the above bug workarounds.
|
|
|
|
=back
|
|
|
|
It is safe and recommended to use SSL_OP_ALL to enable the bug workaround
|
|
options.
|
|
|
|
The following B<modifying> options are available:
|
|
|
|
=over 4
|
|
|
|
=item SSL_OP_TLS_ROLLBACK_BUG
|
|
|
|
Disable version rollback attack detection.
|
|
|
|
During the client key exchange, the client must send the same information
|
|
about acceptable SSL/TLS protocol levels as during the first hello. Some
|
|
clients violate this rule by adapting to the server's answer. (Example:
|
|
the client sends a SSLv2 hello and accepts up to SSLv3.1=TLSv1, the server
|
|
only understands up to SSLv3. In this case the client must still use the
|
|
same SSLv3.1=TLSv1 announcement. Some clients step down to SSLv3 with respect
|
|
to the server's answer and violate the version rollback protection.)
|
|
|
|
=item SSL_OP_SINGLE_DH_USE
|
|
|
|
Always create a new key when using temporary/ephemeral DH parameters
|
|
(see L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>).
|
|
This option must be used to prevent small subgroup attacks, when
|
|
the DH parameters were not generated using "strong" primes
|
|
(e.g. when using DSA-parameters, see L<dhparam(1)|dhparam(1)>).
|
|
If "strong" primes were used, it is not strictly necessary to generate
|
|
a new DH key during each handshake but it is also recommended.
|
|
SSL_OP_SINGLE_DH_USE should therefore be enabled whenever
|
|
temporary/ephemeral DH parameters are used.
|
|
|
|
=item SSL_OP_EPHEMERAL_RSA
|
|
|
|
Always use ephemeral (temporary) RSA key when doing RSA operations
|
|
(see L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>).
|
|
According to the specifications this is only done, when a RSA key
|
|
can only be used for signature operations (namely under export ciphers
|
|
with restricted RSA keylength). By setting this option, ephemeral
|
|
RSA keys are always used. This option breaks compatibility with the
|
|
SSL/TLS specifications and may lead to interoperability problems with
|
|
clients and should therefore never be used. Ciphers with EDH (ephemeral
|
|
Diffie-Hellman) key exchange should be used instead.
|
|
|
|
=item SSL_OP_CIPHER_SERVER_PREFERENCE
|
|
|
|
When choosing a cipher, use the server's preferences instead of the client
|
|
preferences. When not set, the SSL server will always follow the clients
|
|
preferences. When set, the SSLv3/TLSv1 server will choose following its
|
|
own preferences. Because of the different protocol, for SSLv2 the server
|
|
will send his list of preferences to the client and the client chooses.
|
|
|
|
=item SSL_OP_PKCS1_CHECK_1
|
|
|
|
...
|
|
|
|
=item SSL_OP_PKCS1_CHECK_2
|
|
|
|
...
|
|
|
|
=item SSL_OP_NETSCAPE_CA_DN_BUG
|
|
|
|
If we accept a netscape connection, demand a client cert, have a
|
|
non-self-sighed CA which does not have it's CA in netscape, and the
|
|
browser has a cert, it will crash/hang. Works for 3.x and 4.xbeta
|
|
|
|
=item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG
|
|
|
|
...
|
|
|
|
=item SSL_OP_NO_SSLv2
|
|
|
|
Do not use the SSLv2 protocol.
|
|
|
|
=item SSL_OP_NO_SSLv3
|
|
|
|
Do not use the SSLv3 protocol.
|
|
|
|
=item SSL_OP_NO_TLSv1
|
|
|
|
Do not use the TLSv1 protocol.
|
|
|
|
=back
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
SSL_CTX_set_options() and SSL_set_options() return the new options bitmask
|
|
after adding B<options>.
|
|
|
|
SSL_CTX_get_options() and SSL_get_options() return the current bitmask.
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<ssl(3)|ssl(3)>, L<SSL_new(3)|SSL_new(3)>, L<SSL_clear(3)|SSL_clear(3)>,
|
|
L<SSL_CTX_set_tmp_dh_callback(3)|SSL_CTX_set_tmp_dh_callback(3)>,
|
|
L<SSL_CTX_set_tmp_rsa_callback(3)|SSL_CTX_set_tmp_rsa_callback(3)>,
|
|
L<dhparam(1)|dhparam(1)>
|
|
|
|
=head1 HISTORY
|
|
|
|
SSL_OP_CIPHER_SERVER_PREFERENCE has been added in OpenSSL 0.9.7.
|
|
|
|
SSL_OP_TLS_ROLLBACK_BUG has been added in OpenSSL 0.9.6 and was automatically
|
|
enabled with SSL_OP_ALL. As of 0.9.7 it is no longer included in SSL_OP_ALL
|
|
and must be explicitly set.
|
|
|
|
=cut
|