|
|
SSL_CTX_set_options(3)
Contents
|
SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options,
SSL_get_options - Manipulate SSL engine options
#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 );
The SSL_CTX_set_options() function adds the options set
via bitmask in options to ctx. Options already set before
are not cleared.
The SSL_set_options() function adds the options set via
bitmask in options to ssl. Options already set before are
not cleared.
The SSL_CTX_get_options() function returns the options set
for ctx.
The SSL_get_options() function returns the options set for
ssl.
The behavior of the SSL library can be changed by setting
several options. The options are coded as bitmasks and
can be combined by a logical or operation (|). Options can
only be added; they can never be reset.
The SSL_CTX_set_options() and SSL_set_options() functions
affect the (external) protocol behavior of the SSL
library. The (internal) behavior of the API can be
changed by using the similar SSL_CTX_set_mode() and
SSL_set_mode() 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 ctx do not affect already created SSL objects.
The SSL_clear() function does not affect the settings.
The following bug workaround options are available:
www.microsoft.com, when talking SSLv2, if session-id reuse
is performed, the session-id passed back in the serverfinished
message is different from the one decided upon.
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
acceptable, but it should be acceptable also to use 32.
According to SSLv3 specifications, you should use 32 bytes
for the challenge when operating in SSLv2/v3 compatibility
mode, but this breaks the server. So, 16 bytes is preferable.
ssl3.netscape.com:443, first a connection is established
with RC4-MD5. If it resumes, you use 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 shows up
when connecting via SSLv2/v3 then reconnecting via
SSLv3. The cipher list changes.
Try connecting with a cipher list of DES-CBCSHA:RC4-MD5.
Each new connection uses RC4-MD5, but
a reconnect tries to use DES-CBC-SHA. So, Netscape
always takes the first cipher in the cipher list
when doing a reconnect. ... ... ... ... ...
... 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 an
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.) Disables a countermeasure
against an SSL 3.0/TLS 1.0 protocol vulnerability
affecting CBC ciphers, which cannot be handled
by some broken SSL implementations. This
option has no effect for connections using other
ciphers. All of the above bug workarounds.
It is usually safe to use SSL_OP_ALL to enable the bug
workaround options if compatibility with somewhat broken
implementations is desired.
The following modifying options are available: Always create
a new key when using temporary/ephemeral DH parameters
(see SSL_CTX_set_tmp_dh_callback()). 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 dhparam()). If "strong"
primes were used, it is not necessary to generate a new DH
key during each handshake, but it is recommended.
SSL_OP_SINGLE_DH_USE should therefore be enabled whenever
temporary/ephemeral DH parameters are used. Always use
ephemeral (temporary) RSA key when doing RSA operations
(see SSL_CTX_set_tmp_rsa_callback()). According to the
specifications, this is only done when an 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.
Therefore, it should never be used. Ciphers with EDH
(ephemeral Diffie-Hellman) key exchange should be used
instead. ... ... If you accept a Netscape connection,
demand a client cert, have a non-self-signed CA which does
not have its CA in netscape, and the browser has a cert,
it will crash/hang. Works for 3.x and 4.xbeta ... Do not
use the SSLv2 protocol. Do not use the SSLv3 protocol.
Do not use the TLSv1 protocol.
The SSL_CTX_set_options() and SSL_set_options() functions
return the new options bitmask after adding options.
The SSL_CTX_get_options() and SSL_get_options() functions
return the current bitmask.
SSL_OP_TLS_ROLLBACK_BUG was added in OpenSSL 0.9.6.
SSL_OP_DONT INSERT_EMPTY_FRAGMENTS has been added in
OpenSSL 0.9.6e. Versions up to OpenSSL 0.9.6c do not
include the countermeasure that can be disabled with this
option. In OpenSSL 0.9.6d it was always enabled.
Commands: dhparam(1)
Functions: ssl(3), SSL_CTX_set_tmp_dh_callback(3),
SSL_CTX_set_tmp_rsa_callback(3), SSL_new(3), SSL_clear(3)
SSL_CTX_set_options(3)
[ Back ] |
