X-Git-Url: https://git.openssl.org/gitweb/?p=openssl.git;a=blobdiff_plain;f=doc%2Fssl%2FSSL_CTX_set_options.pod;h=84dde2805ec2d3119ded9a0f1136b89d9ee5caa3;hp=a878a6af6dc991316406eebf547d11a6659e924e;hb=a8e4ac6a2fe67c19672ecf0c6aeafa15801ce3a5;hpb=9fb6fd34f8e2c2604ddb5474381aea7c25011b9c diff --git a/doc/ssl/SSL_CTX_set_options.pod b/doc/ssl/SSL_CTX_set_options.pod index a878a6af6d..84dde2805e 100644 --- a/doc/ssl/SSL_CTX_set_options.pod +++ b/doc/ssl/SSL_CTX_set_options.pod @@ -44,7 +44,7 @@ secure renegotiation. =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 +The options are coded as bitmasks and can be combined by a bitwise B operation (|). SSL_CTX_set_options() and SSL_set_options() affect the (external) @@ -63,33 +63,15 @@ The following B options are available: =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. +As of OpenSSL 1.0.0 this option has no effect. =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. +As of OpenSSL 1.0.0 this option has no effect. =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. +As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect. =item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG @@ -99,9 +81,10 @@ doing a re-connect, always takes the first cipher in the cipher list. ... -=item SSL_OP_MSIE_SSLV2_RSA_PADDING +=item SSL_OP_SAFARI_ECDHE_ECDSA_BUG -As of OpenSSL 0.9.7h and 0.9.8a, this option has no effect. +Don't prefer ECDHE-ECDSA ciphers when the client appears to be Safari on OS X. +OS X 10.8..10.8.3 has broken support for ECDHE-ECDSA ciphers. =item SSL_OP_SSLEAY_080_CLIENT_DH_BUG @@ -111,10 +94,6 @@ As of OpenSSL 0.9.7h and 0.9.8a, this option has no effect. ... -=item SSL_OP_TLS_BLOCK_PADDING_BUG - -... - =item SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS Disables a countermeasure against a SSL 3.0/TLS 1.0 protocol @@ -122,6 +101,12 @@ vulnerability affecting CBC ciphers, which cannot be handled by some broken SSL implementations. This option has no effect for connections using other ciphers. +=item SSL_OP_TLSEXT_PADDING + +Adds a padding extension to ensure the ClientHello size is never between +256 and 511 bytes in length. This is needed as a workaround for some +implementations. + =item SSL_OP_ALL All of the above bug workarounds. @@ -162,15 +147,7 @@ temporary/ephemeral DH parameters are used. =item SSL_OP_EPHEMERAL_RSA -Always use ephemeral (temporary) RSA key when doing RSA operations -(see L). -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. +This option is no longer implemented and is treated as no op. =item SSL_OP_CIPHER_SERVER_PREFERENCE @@ -188,15 +165,7 @@ will send its list of preferences to the client and the client chooses. ... -=item SSL_OP_NETSCAPE_CA_DN_BUG -If we 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 - -=item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG - -... =item SSL_OP_NO_SSLv2 @@ -224,20 +193,26 @@ of RFC4507bis tickets for stateless session resumption. If this option is set this functionality is disabled and tickets will not be used by clients or servers. -=item SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, SSL_OP_LEGACY_SERVER_CONNECT +=item SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION -See the B section for a discussion of the purpose of -these options. +Allow legacy insecure renegotiation between OpenSSL and unpatched clients or +servers. See the B section for more details. + +=item SSL_OP_LEGACY_SERVER_CONNECT + +Allow legacy insecure renegotiation between OpenSSL and unpatched servers +B: this option is currently set by default. See the +B section for more details. =back =head1 SECURE RENEGOTIATION OpenSSL 0.9.8m and later always attempts to use secure renegotiation as -described in draft-ietf-tls-renegotiation (FIXME: replace by RFC). This -counters the prefix attack described in CVE-2009-3555 and elsewhere. +described in RFC5746. This counters the prefix attack described in +CVE-2009-3555 and elsewhere. -The deprecated and highly broken SSLv2 protocol does not support secure +The deprecated and highly broken SSLv2 protocol does not support renegotiation at all: its use is B discouraged. This attack has far reaching consequences which application writers should be @@ -254,7 +229,7 @@ Connections and renegotiation are always permitted by OpenSSL implementations. =head2 Unpatched client and patched OpenSSL server -The initial connection suceeds but client renegotiation is denied by the +The initial connection succeeds but client renegotiation is denied by the server with a B warning alert if TLS v1.0 is used or a fatal B alert in SSL v3.0. @@ -275,11 +250,18 @@ was refused. =head2 Patched OpenSSL client and unpatched server. -If the option B is set then initial connections -between patched OpenSSL clients and unpatched servers succeed. This option -is currently set by default even though it has security implications: otherwise -it would be impossible to connect to unpatched servers (i.e. all of them -initially) and this is clearly not acceptable. +If the option B or +B is set then initial connections +and renegotiation between patched OpenSSL clients and unpatched servers +succeeds. If neither option is set then initial connections to unpatched +servers will fail. + +The option B is currently set by default even +though it has security implications: otherwise it would be impossible to +connect to unpatched servers (i.e. all of them initially) and this is clearly +not acceptable. Renegotiation is permitted because this does not add any +additional security issues: during an attack clients do not see any +renegotiations anyway. As more servers become patched the option B will B be set by default in a future version of OpenSSL. @@ -292,10 +274,12 @@ unpatched servers (and thus avoid any security issues) should always B B using SSL_CTX_clear_options() or SSL_clear_options(). -Renegotiation between a patched OpenSSL client and unpatched server follows -the same scheme as between an unpatched client and a patched OpenSSL server: -i.e. it is not permitted unless the option -B is set. +The difference between the B and +B options is that +B enables initial connections and secure +renegotiation between OpenSSL clients and unpatched servers B, while +B allows initial connections +and renegotiation between OpenSSL and unpatched clients or servers. =head1 RETURN VALUES