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 Tue, 10 Nov 2009 00:09:50 GMT
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.


Costin

On Mon, Nov 9, 2009 at 1:32 PM, Costin Manolache <costin@gmail.com> wrote:

>
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message