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 Mon, 09 Nov 2009 21:32:04 GMT
On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache <costin@gmail.com> wrote:

>
>
> On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko <knst.kolinko@gmail.com
> > wrote:
>
>> 2009/11/9 Mark Thomas <markt@apache.org>:
>> > Summarising the information gathered so far from various channels
>> > (thanks to Bill B., Bill W. & Rainer who have done most of the actual
>> > work to find the info below).
>> >
>> > BIO/NIO connectors using JSSE.
>> > Vulnerable when renegotiation is triggered by the client or server.
>> > We could prevent server initiated renegotiation (and probably break the
>> > majority of configurations using CLIENT-CERT).
>> > We can't do anything to prevent client initiated renegotiation.
>> >
>> > APR/native connector using OpenSSL
>> > It is vulnerable when renegotiation is triggered by the client or by the
>> > server.
>> > Client triggered negotiation is supported.
>> > Server triggered negotiation will be supported from 1.1.17 onwards.
>> >
>> > OpenSSL 0.9.8l disables negotiation by default
>> >
>> >
>> > In terms of what this means for users:
>> >
>> > BIO/NIO
>> > - There isn't anything we can do in Tomcat to stop client
>> >  initiated renegotiation so it is a case of waiting for the JVM
>> >  vendors to respond.
>> >
>> > APR/native
>> > - Re-building their current version with 0.9.8l will protect
>> >  users at the risk of breaking any configurations that
>> >  require renegotiation.
>> > - We can release 1.1.17 with the binaries built with 0.9.8l. This
>> >  will also protect users at the risk of breaking any
>> >  configurations that require renegotiation. Mladen is doing this
>> >  now.
>> > - Supporting renegotiation whilst avoiding the vulnerability will
>> >  require a protocol fix. In the meantime, we could port port
>> >  r833582 from httpd which would disable client triggered
>> >  renegotiation for OpenSSL < 0.9.8l (which may help some users
>> >  who can't easily change their OpenSSl version and release 1.1.18
>> >  with this fix
>> > - Once the protocol is fixed, release 1.1.next bundled with the
>> >  appropriate version of OpenSSL
>> >
>> >
>> > Have I got my facts right above? If so, any objections to posting the
>> > above to the users@ and announce@ lists along with adding something to
>> > the security pages?
>> >
>> > Mark
>> >
>>
>> +1
>>
>> s/negotiation/renegotiation/
>> s/port port/port/
>>
>> A question:
>> My understanding of renegotiation is that it changes SSL session. Is
>> it possible to observe changes in the value of SSL sessionId?  I doubt
>> so, but may be?
>>
>
> AFAIK you can reuse the session ID across negotiations ( it's a nice
> optimization BTW, too
> bad we're not using, it can speed up SSL connections a lot ), I'm not sure
> if it changes
> within a renegotation, but AFAIK when you start any negotiation you can
> specify you want
> to reuse the old session id.  But if I understand the exploit correctly -
> they would want a different
> cypher, and if you reuse the session you reuse the old one.
>
>
> Maybe we can modify JSSESupport.Listener to break the connection if
> handshakeCompleted is
> called > once in a connection ? That is besides disabling server-initiated
> handshakes.
>
>

BTW - confirmed that JSSESupport.Listener is called when client does
re-negotiate, but it is not called on the first
negotiation ( it's added too late ).

However it's pretty easy to add a listener earlier, patch attached - it
should break all client re-negotiations, so we don't need
to wait for a JDK fix.

I wrote a small unit test - but I'm can't seem to get jsse client to
re-negotiate for the test, can only do it using command line
openssl. The patch seems to work - but you need so system properties  or
flags if we want to let people
 disable this ( "allowManInTheMiddle" is a good name for a flag ).  Also the
test needs a bit of work.

If anyone has more time, my 20% is getting low ....


Costin



> Costin
>
>
>
>> We read that value once and provide it to our users as
>> "javax.servlet.request.ssl_session" request attribute.
>>
>> Regarding valves (as mentioned in issue 48157):
>> I understand, that that is not sufficient, but if anyone wants to
>> check against malformed headers, they can do so.
>>
>> Best regards,
>> Konstantin Kolinko
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>

Mime
View raw message