SSL_CTX_set_options(3)SSL_CTX_set_options(3)NAME
SSL_CTX_set_options, SSL_set_options, SSL_CTX_get_options,
SSL_get_options - Manipulate SSL engine options
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 );
DESCRIPTION
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.
NOTES
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) behav‐
ior 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 set‐
tings.
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 server-finished 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 com‐
patibility mode, but this breaks the server. So, 16 bytes is prefer‐
able. 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-CBC-SHA: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 gener‐
ated using "strong" primes (e.g. when using DSA-parameters, see
dhparam()). If "strong" primes were used, it is not necessary to gen‐
erate a new DH key during each handshake, but it is recommended.
SSL_OP_SINGLE_DH_USE should therefore be enabled whenever tempo‐
rary/ephemeral DH parameters are used. Always use ephemeral (tempo‐
rary) RSA key when doing RSA operations (see SSL_CTX_set_tmp_rsa_call‐
back()). 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.
RETURN VALUES
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.
HISTORY
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.
SEE ALSO
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)