tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cos...@gmail.com>
Subject Re: SSL & Tomcat
Date Wed, 18 Nov 2009 16:08:16 GMT
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 <sign@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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message