We have used SSLProtocol="SSLv3+TLSv1" with the APR connectors in 6.0.x and 7.0.x successfully to support both SSLv3 and TLSv1 protocols exclusively (no SSLv2 support). The following openssl s_client connection tests demonstrate this functionality with 7.0.8: $ openssl s_client -connect eiger.middleware.vt.edu:443 -tls1 CONNECTED(00000003) ... SSL handshake has read 6158 bytes and written 293 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 ... $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl3 CONNECTED(00000003) ... SSL handshake has read 6027 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : SSLv3 ... $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl2 15389:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453: Upon upgrading to Tomcat 7.0.16, which includes the fix for https://issues.apache.org/bugzilla/show_bug.cgi?id=51073, our desired protocol combination fails with the expected "unsupported protocol" message. Unfortunately, none of the officially supported strings mentioned at http://tomcat.apache.org/tomcat-7.0-doc/config/http.html#SSL%20Support provide the desired protocol support. In particular the protocol values are exclusive, where setting SSLProtocol="SSLv3" prevents TLSv1 connections and vice versa. The following s_client tests confirm this behavior: (7.0.16 with SSLProtocol="SSLv3") $ openssl s_client -connect eiger.middleware.vt.edu:443 -tls1 CONNECTED(00000003) 15696:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:293: $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl3 CONNECTED(00000003) ... SSL handshake has read 6027 bytes and written 319 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : SSLv3 ... (7.0.16 with SSLProtocol="TLSv1") $ openssl s_client -connect eiger.middleware.vt.edu:443 -tls1 CONNECTED(00000003) ... SSL handshake has read 6158 bytes and written 293 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 ... $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl3 CONNECTED(00000003) 15816:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1102:SSL alert number 40 15816:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:539:
Set Tomcat version to 7.0.16.
Bugzilla is not a support form. Please subscribe to the Tomcat users list and post your question there. Some hints: if you want the server to speak SSLv3 and TLSv1, you need to set the SSLProtocol to "all". To ensure secure communication you also need to set SSLCipherSuite to something sensible, like e.g. RC4-SHA:AES128-SHA:ALL:!aNULL:!EXP:!LOW:!MD5:!SSLV2:!NULL Please don't proceed the discussion here. If the discussion on the users list gives reason to believe you really hit a bug, you can reopen this issue. Regards, Rainer
According to the source code, before bug 51073 was fixed (r1094089 or r1124211), the "SSLv3+TLSv1" value just worked as a synonym to "all". What happens with ssl2 connections if you configure SSLProtocol="all" - in 7.0.16 - in 7.0.8 does it accept ssl2 connections or rejects them? -- Anyway, I do not mind to add "SSLv3+TLSv1" as an allowed value, if it is actually supported by the library. Looking at implementation of SSLContext.make in sslcontext.c of tc-native 1.1.x, there is code for this combination of flags. http://svn.apache.org/viewvc/tomcat/native/branches/1.1.x/native/src/sslcontext.c?view=markup#l85
But I *think* OpenSSL does not support it: http://www.openssl.org/docs/ssl/SSL_CTX_new.html It looks like you have to do what I already posted here: choose "all" for the protocol and disable any SSLV2 ciphers. Rainer
"SSLv3+TLSv1" value just worked as a synonym to "all" Appears this is correct based on my testing. Setting SSLProtocol="all" in both 7.0.8 and 7.0.16 produced exactly the same results: TLSv1 and SSLv3 are supported but not SSLv2. It appears that our SSLCipherSuite parameter is actually providing the desired behavior: SSLCipherSuite="HIGH:MEDIUM:-SSLv2" So we'll be able to preserve the desired functionality with SSLProtocol="all" in versions 7.0.16 and later. I think there's merit in supporting other protocol combinations that make sense if for no other reason to maintain consistency with mod_ssl directives of the same name, which are eerily similar to APR connector attributes. (I've assumed that similarity is intentional.)
I verified the following mod_ssl directives provide equivalent behavior (no SSLv2): SSLProtocol +SSLv3 +TLSv1 SSLCipherSuite HIGH:MEDIUM
I checked the code of tcnative and of mod_ssl. Both have provisions for arbitrary combinations in SSLProtocol. The way it works is there's a basic protocol selection in OpenSSL and then you can remove parts by adding an option. The possible basic settings are SSLv2, SSLv3, TLSv1 and SSLv23. All except for the last one *only* understand that specific protocol, the last one understand SSLv2, SSLv3 *and* TLSv1, so this is "all". For arbitrary combinations one chooses SSLv23 and then removes the protocols one doesn't want via SSL_CTX_set_options() using the options SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3 and/or SSL_OP_NO_TLSv1. In tcnative in sslcontext.c there seems to be a bug in choosing SSLv2 if the configured protocol is SSLv2+TLSv1 and choosing SSLv3 if it is SSLv3+TLSv1. I'd say in both cases it should be SSLv23, because neither SSLV2 not SSLV3 support TLSv1. The additional protocol in SSLv23 is later removed via the options. Fortunately those combinations do not yet get passed down by AprEndpoint.java. But yes, it'd be easy to support any combination.
Created attachment 27260 [details] Support for arbitrary protocol combinations The combinations SSLv2+TLSv1 and SSLv3+TLSv1 will only work, if tcnative is patched as well. Patch is untested.
I've reviewed the patch and it appears that it doesn't do the work of removing protocols via SSL_CTX_set_options() as you mentioned. At this point it appears all supported strings will end up supporting SSLv2+SSLv3+TLSv1 due to the use of SSLv23_client_method(), which is not the equivalent behavior of similar mod_ssl directives.
I dug a little further and found that the requisite SSL_CTX_set_options() calls are already in sslcontext.c. I'll test the patch and report back.
I tested the patch and verified that SSLv3+TLSv1 works as expected, allowing SSLv3 and TLSv1, but denying SSLv2 connections. However, the setting SSLv2+TLSv1 only allows TLSv1 connections: $ openssl s_client -connect eiger.middleware.vt.edu:443 -tls1 CONNECTED(00000003) ... SSL handshake has read 6158 bytes and written 293 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1 $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl2 25335:error:140A90C4:SSL routines:SSL_CTX_new:null ssl method passed:ssl_lib.c:1453: $ openssl s_client -connect eiger.middleware.vt.edu:443 -ssl3 CONNECTED(00000003) 25338:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1102:SSL alert number 40 25338:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:539:
Which SSLCipher did you use?
While OpenSSL's s_client can certainly get the job done, you might make things easier on yourself by using sslscan (http://sourceforge.net/projects/sslscan/). Most Linux distros have packages for it, too.
There is no SSLCipherSuite attribute defined for the SSL connector. See attached server.xml file.
Created attachment 27274 [details] Test server.xml
I tested it now myself and it *does* work for me with all 8 possible combinations, each only allowing the configured protocol set. Maybe your OpenSSL client doesn't allow SSLv2? What happens if you set the SSLProtocol in the connector to SSLv2?
I applied a slightly revised version of the patch in r1145209. The new support for arbitrary protocol combinations will need a release of tcnative. For existing releases there will be only support for the documented combinations, because other combinations will give unexpected results. I'll keep this issue open and reassign to tcnative.
Support is in tcnative starting with 1.2.22.
Change also proposed for Tomcat 6.
Applied to 6.0 in r1304509 and will be in 6.0.36
*** Bug 53344 has been marked as a duplicate of this bug. ***