Bug 48236 - another workaround for CVE-2009-3555 for the BIO connector
Summary: another workaround for CVE-2009-3555 for the BIO connector
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:Coyote (show other bugs)
Version: 5.5.28
Hardware: All All
: P2 major (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 48158 (view as bug list)
Depends on:
Reported: 2009-11-19 04:51 UTC by keilh
Modified: 2010-01-30 11:18 UTC (History)
2 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description keilh 2009-11-19 04:51:14 UTC
Since Revision 881774 of org/apache/tomcat/util/net/jsse/JSSESocketFactory.java
SSL renegotiation can be disabled.

That is achieved by a HandshakeCompletedListener. The drawback is, that in the
JSSE from SUN any HandshakeCompletedListener will be invoked by with an own 
thread. (See com.sun.net.ssl.internal.ssl.SSLSocketImpl or the fragment below)

Another way of disabling a SSL renegotiation is to set an empty cipher
list after the initial handshake:

public void handshake(Socket sock) throws IOException {
        if(!allowUnsafeLegacyRenegotiation) {
            // disable all ciphers, avoiding any subsequent handshake 
            ((SSLSocket)sock).setEnabledCipherSuites(new String[0]);


com.sun.net.ssl.internal.ssl.SSLSocketImpl code fragment:

if (handshaker.isDone()) {
                        sess = handshaker.getSession();
                        handshaker = null;
                        connectionState = cs_DATA;

                        // Tell folk about handshake completion, but do
                        // it in a separate thread.
                        if (handshakeListeners != null) {
                            HandshakeCompletedEvent event =
                                new HandshakeCompletedEvent(this, sess);

                            Thread t = new NotifyHandshakeThread(
                                handshakeListeners.entrySet(), event);
Comment 1 Mark Thomas 2009-11-19 05:44:36 UTC
Thanks for the alternative suggestion. I'll do some testign and if all looks OK, change the way we disable the handshake.
Comment 2 Mark Thomas 2009-11-19 13:38:59 UTC
*** Bug 48158 has been marked as a duplicate of this bug. ***
Comment 3 Mark Thomas 2009-11-19 13:41:24 UTC
Testing has been positive. I ended up keeping the listener from the original patch to log the handshake attempts. I'm not so concerned about the logging being in a separate thread and it was the easiest (only?) way to hook into the client triggered handshakes.

Patch to trunk will follow shortly.
Comment 4 Ralf Hauser 2009-11-19 22:00:46 UTC
Are there any junit or rather httpclient/httpunit tests for this?
Or at least a detailed test script (e.g. documented in a wiki)?

Looking forward to the new patch.
Comment 5 Mark Thomas 2009-11-20 01:48:50 UTC
Nothing formal, and the nature of the tests is such it might take a little longer than usual to set up something with the Tomcat JUnit tests.

My testing uses a simple webapp that uses CLIENT-CERT and has one JSP that is protected by a security constraint.

To test client renegotiation, I use openssl s_client and the R command
To test server renegotiation, I use Firefox or IE and browse between the Tomcat homepage and the protected page.
Comment 6 Mark Thomas 2009-11-22 15:26:22 UTC
There is also org.apache.catalina.startup.TestTomcatSSL although a couple of tests are failing at the moment and I need to figure out why. I suspect it is because of some recent refactoring.
Comment 7 Mark Thomas 2010-01-11 09:49:32 UTC
The alternative patch has been applied to 6.0.x and will be included in  6.0.21 onwards.
Comment 8 Mark Thomas 2010-01-30 11:18:54 UTC
The new patch has been applied to 5.5.x and will be included in 5.5.29 onwards.