Bug 51477 - Support all protocol combinations in SSLProtocol of APR Connector
Summary: Support all protocol combinations in SSLProtocol of APR Connector
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Native
Classification: Unclassified
Component: Library (show other bugs)
Version: 1.1.20
Hardware: PC Linux
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords: PatchAvailable
: 53344 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-05 16:53 UTC by Marvin Addison
Modified: 2012-06-01 12:18 UTC (History)
1 user (show)



Attachments
Support for arbitrary protocol combinations (5.02 KB, patch)
2011-07-05 19:29 UTC, Rainer Jung
Details | Diff
Test server.xml (3.53 KB, application/xml)
2011-07-08 12:30 UTC, Marvin Addison
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marvin Addison 2011-07-05 16:53:25 UTC
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:
Comment 1 Marvin Addison 2011-07-05 16:53:58 UTC
Set Tomcat version to 7.0.16.
Comment 2 Rainer Jung 2011-07-05 17:39:34 UTC
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
Comment 3 Konstantin Kolinko 2011-07-05 17:55:18 UTC
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
Comment 4 Rainer Jung 2011-07-05 18:15:52 UTC
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
Comment 5 Marvin Addison 2011-07-05 18:19:26 UTC
"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.)
Comment 6 Marvin Addison 2011-07-05 18:31:40 UTC
I verified the following mod_ssl directives provide equivalent behavior (no SSLv2):

SSLProtocol +SSLv3 +TLSv1
SSLCipherSuite HIGH:MEDIUM
Comment 7 Rainer Jung 2011-07-05 18:50:45 UTC
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.
Comment 8 Rainer Jung 2011-07-05 19:29:12 UTC
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.
Comment 9 Marvin Addison 2011-07-05 19:49:48 UTC
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.
Comment 10 Marvin Addison 2011-07-05 19:58:09 UTC
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.
Comment 11 Marvin Addison 2011-07-07 16:00:45 UTC
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:
Comment 12 Rainer Jung 2011-07-07 16:49:49 UTC
Which SSLCipher did you use?
Comment 13 Christopher Schultz 2011-07-07 19:00:36 UTC
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.
Comment 14 Marvin Addison 2011-07-08 12:29:15 UTC
There is no SSLCipherSuite attribute defined for the SSL connector.  See attached server.xml file.
Comment 15 Marvin Addison 2011-07-08 12:30:24 UTC
Created attachment 27274 [details]
Test server.xml
Comment 16 Rainer Jung 2011-07-10 15:04:12 UTC
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?
Comment 17 Rainer Jung 2011-07-11 15:46:33 UTC
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.
Comment 18 Rainer Jung 2012-02-12 10:14:18 UTC
Support is in tcnative starting with 1.2.22.
Comment 19 Rainer Jung 2012-02-20 17:54:40 UTC
Change also proposed for Tomcat 6.
Comment 20 Konstantin Kolinko 2012-03-23 17:27:16 UTC
Applied to 6.0 in r1304509 and will be in 6.0.36
Comment 21 Konstantin Kolinko 2012-06-01 12:18:09 UTC
*** Bug 53344 has been marked as a duplicate of this bug. ***