=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
...
-=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
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.
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
+clients and should therefore never be used. Ciphers with DHE (ephemeral
Diffie-Hellman) key exchange should be used instead.
=item SSL_OP_CIPHER_SERVER_PREFERENCE
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<SECURE RENEGOTIATION> section for a discussion of the purpose of
-these options.
+Allow legacy insecure renegotiation between OpenSSL and unpatched clients or
+servers. See the B<SECURE RENEGOTIATION> section for more details.
+
+=item SSL_OP_LEGACY_SERVER_CONNECT
+
+Allow legacy insecure renegotiation between OpenSSL and unpatched servers
+B<only>: this option is currently set by default. See the
+B<SECURE RENEGOTIATION> 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<strongly> discouraged.
This attack has far reaching consequences which application writers should be
=head2 Patched OpenSSL client and unpatched server.
-If the option B<SSL_OP_LEGACY_SERVER_CONNECT> 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<SSL_OP_LEGACY_SERVER_CONNECT> or
+B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> 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<SSL_OP_LEGACY_SERVER_CONNECT> 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<SSL_OP_LEGACY_SERVER_CONNECT> will
B<not> be set by default in a future version of OpenSSL.
B<SSL_OP_LEGACY_SERVER_CONNECT> 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<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> is set.
+The difference between the B<SSL_OP_LEGACY_SERVER_CONNECT> and
+B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> options is that
+B<SSL_OP_LEGACY_SERVER_CONNECT> enables initial connections and secure
+renegotiation between OpenSSL clients and unpatched servers B<only>, while
+B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> allows initial connections
+and renegotiation between OpenSSL and unpatched clients or servers.
=head1 RETURN VALUES