Clarify warning
[openssl.git] / doc / ssl / SSL_CTX_set_options.pod
index 7ffe9481121c734b2c13cb0d8b8d12c30782eb0f..cc588f3a78f3a302a4b422bc2fdc9dc55728e5d9 100644 (file)
@@ -78,18 +78,7 @@ 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.
+As of OpenSSL 0.9.8q and 1.0.0c, this option has no effect.
 
 =item SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG
 
@@ -224,37 +213,49 @@ 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
+
+Allow legacy insecure renegotiation between OpenSSL and unpatched clients or
+servers. See the B<SECURE RENEGOTIATION> section for more details.
 
-See the B<SECURE RENEGOTIATION> section for a discussion of the purpose of
-these options.
+=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
+renegotiation at all: its use is B<strongly> discouraged.
 
 This attack has far reaching consequences which application writers should be
 aware of. In the description below an implementation supporting secure
 renegotiation is referred to as I<patched>. A server not supporting secure
 renegotiation is referred to as I<unpatched>.
 
+The following sections describe the operations permitted by OpenSSL's secure
+renegotiation implementation.
+
 =head2 Patched client and server
 
-Connections and renegotiation will always succeed.
+Connections and renegotiation are always permitted by OpenSSL implementations.
 
-=head2 Unpatched client and patched server
+=head2 Unpatched client and patched OpenSSL server
 
-The initial connection suceeds but client renegotiation is denied with a
-B<no_renegotiation> warning alert if TLS v1.0 is used or a fatal
+The initial connection suceeds but client renegotiation is denied by the
+server with a B<no_renegotiation> warning alert if TLS v1.0 is used or a fatal
 B<handshake_failure> alert in SSL v3.0.
 
-If the patched server attempts to renegotiate a fatal B<handshake_failure>
-alert is sent. This is because the server code may be unaware of the
-unpatched nature of the client.
+If the patched OpenSSL server attempts to renegotiate a fatal
+B<handshake_failure> alert is sent. This is because the server code may be
+unaware of the unpatched nature of the client.
 
 If the option B<SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION> is set then
 renegotiation B<always> succeeds.
@@ -263,32 +264,42 @@ B<NB:> a bug in OpenSSL clients earlier than 0.9.8m (all of which are
 unpatched) will result in the connection hanging if it receives a
 B<no_renegotiation> alert. OpenSSL versions 0.9.8m and later will regard
 a B<no_renegotiation> alert as fatal and respond with a fatal
-B<handshake_failure> alert.
+B<handshake_failure> alert. This is because the OpenSSL API currently has
+no provision to indicate to an application that a renegotiation attempt
+was refused.
+
+=head2 Patched OpenSSL client and unpatched server.
 
-=head2 Patched client and unpatched server.
+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.
 
-If the option B<SSL_OP_LEGACY_SERVER_CONNECT> is set then initial connections
-to unpatched servers succeed. This option is currently set by default even
+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.
+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.
 
-Applications that want to ensure they can connect to unpatched servers should
-always B<set> B<SSL_OP_LEGACY_SERVER_CONNECT>
+OpenSSL client applications wishing to ensure they can connect to unpatched
+servers should always B<set> B<SSL_OP_LEGACY_SERVER_CONNECT>
 
-Applications that want to ensure they can B<not> connect to unpatched servers
-(and thus avoid any security issues) should always B<clear>
+OpenSSL client applications that want to ensure they can B<not> connect to
+unpatched servers (and thus avoid any security issues) should always B<clear>
 B<SSL_OP_LEGACY_SERVER_CONNECT> using SSL_CTX_clear_options() or
 SSL_clear_options().
 
-The function SSL_get_secure_renegotiation_support() indicates whether the peer
-supports secure renegotiation. 
-
-The deprecated and highly broken SSLv2 protocol does not support secure
-renegotiation at all: its use is B<strongly> discouraged.
+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