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.
>
