Good catch ! If the listener is called in a separate thread, as it seems from your debugging - the attacker may have a small window when he can still push data - and potentially get the request executed. I guess the probability is extremely small - but theoretically can be done.
I'll try it - the solution would be to not read any application data until we know the handshake is completed, for example a lock. For the NIO connector - still all fine, since re-negotiation can't even start, I don't think openssl has this problem either. Costin On Wed, Nov 18, 2009 at 5:59 AM, Luciana Moreira Sa de Souza Signed by - PrivaSphere AG <s...@privasphere.com> wrote: > Hello, > > I just added the patch created by Costin Manolache to prevent the MITM > attack during re-negotiations for JSSE to our platform. I performed some > tests and at first I found the solution quite elegant. Nevertheless, when I > did some debugging to verify if everything was really fine I noticed one > thing. > > It seems that this is a asynchronous approach. When I put a breakpoint in > the following code the connection was not interrupted. > > public void handshakeCompleted(HandshakeCompletedEvent event) { > if (completed) { > > Even after executing the following code I could continue to navigate > through the website. It seems to me that for some reason the connection is > not interrupted if there is a certain delay on the execution of the code > bellow. > > log.warn("SSL renegotiation is disabled, closing > connection"); > event.getSession().invalidate(); > event.getSocket().close(); > > It seems to me that the approach with the Listener is asynchronous but at > the same time this solution seems to require some synchrony to work > properly. > > So my question to you is: > How safe this solution is if the server becomes overloaded and delays the > execution of the HandshakeCompletedListener? > > FYI, I ported the patch to tomcat 5.5 which is the one we are currently > using in our platform. I don't know if this could change the time behaviour > of the patch. > > > Regards, > Luciana Moreira > > Costin Manolache wrote: > >> Unless someone has a better solution - I'll submit the fix ( tonight ), >> will >> disable re-negotiation for >> Jsse-mode. >> I added a system property to allow people how don't care about this, IMO >> by >> default it should >> be on. >> >> Also got the test case to work - please let me know if it's acceptable to >> commit it, it depends >> on having a .keystore with a 'localhost' cert, didn't find any other SSL >> tests in the suite. >> Forgot that you need to read() after startHandshake() - just cut&pasted >> the >> code from >> JsseSupport and it worked. >> >> > > > > ---------- > This message has been signed by the PrivaSphere Mail Signature Service. >