Clarify protocols supported.

Update protocols supported and note that SSLv2 is effectively disabled
by default.

PR#3184

diff --git a/doc/ssl/SSL_CTX_new.pod b/doc/ssl/SSL_CTX_new.pod
index 23e13e134e61e2681c5ff93bf130a622d1a9dd24..89249df32a1c11892fe1df060653d8974ae948f6 100644 (file)
--- a/doc/ssl/SSL_CTX_new.pod
+++ b/doc/ssl/SSL_CTX_new.pod
@@ -62,22 +62,36 @@ SSLv3 client hello messages.
 
 =item SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
 
-A TLS/SSL connection established with these methods will understand the SSLv2,
-SSLv3, and TLSv1 protocol. A client will send out SSLv2 client hello messages
-and will indicate that it also understands SSLv3 and TLSv1. A server will
-understand SSLv2, SSLv3, and TLSv1 client hello messages. This is the best
-choice when compatibility is a concern.
+A TLS/SSL connection established with these methods may understand the SSLv2,
+SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.
+
+If the cipher list does not contain any SSLv2 ciphersuites (the default
+cipher list does not) or extensions are required (for example server name)
+a client will send out TLSv1 client hello messages including extensions and
+will indicate that it also understands TLSv1.1, TLSv1.2 and permits a
+fallback to SSLv3. A server will support SSLv3, TLSv1, TLSv1.1 and TLSv1.2
+protocols. This is the best choice when compatibility is a concern.
+
+If any SSLv2 ciphersuites are included in the cipher list and no extensions
+are required then SSLv2 compatible client hellos will be used by clients and
+SSLv2 will be accepted by servers. This is B<not> recommended due to the
+insecurity of SSLv2 and the limited nature of the SSLv2 client hello
+prohibiting the use of extensions.
 
 =back
 
 The list of protocols available can later be limited using the SSL_OP_NO_SSLv2,
-SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the B<SSL_CTX_set_options()> or
-B<SSL_set_options()> functions. Using these options it is possible to choose
-e.g. SSLv23_server_method() and be able to negotiate with all possible
-clients, but to only allow newer protocols like SSLv3 or TLSv1.
+SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2
+options of the SSL_CTX_set_options() or SSL_set_options() functions.
+Using these options it is possible to choose e.g. SSLv23_server_method() and
+be able to negotiate with all possible clients, but to only allow newer
+protocols like TLSv1, TLSv1.1 or TLS v1.2.
+
+Applications which never want to support SSLv2 (even is the cipher string
+is configured to use SSLv2 ciphersuites) can set SSL_OP_NO_SSLv2.
 
 SSL_CTX_new() initializes the list of ciphers, the session cache setting,
-the callbacks, the keys and certificates, and the options to its default
+the callbacks, the keys and certificates and the options to its default
 values.
 
 =head1 RETURN VALUES

diff --git a/doc/ssl/SSL_CTX_set_cipher_list.pod b/doc/ssl/SSL_CTX_set_cipher_list.pod
index c2c349f65e7b6c2fea47715f8f8bad111858d31c..8b41917334b7bf95c654a23c7224eba48491372c 100644 (file)
--- a/doc/ssl/SSL_CTX_set_cipher_list.pod
+++ b/doc/ssl/SSL_CTX_set_cipher_list.pod
@@ -54,6 +54,10 @@ of 512 bits and the server is not configured to use temporary RSA
 keys), the "no shared cipher" (SSL_R_NO_SHARED_CIPHER) error is generated
 and the handshake will fail.
 
+If the cipher list does not contain any SSLv2 cipher suites (this is the
+default) then SSLv2 is effectively disabled and neither clients nor servers
+will attempt to use SSLv2.
+
 =head1 RETURN VALUES
 
 SSL_CTX_set_cipher_list() and SSL_set_cipher_list() return 1 if any cipher