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.
smime.p7s
Description: S/MIME cryptographic signature
