tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
Subject Re: SSL & Tomcat
Date Tue, 10 Nov 2009 00:17:42 GMT
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.

Sounds good. Any chance it could be a connector property rather than a
system property? If you don't have a chance to do this I can always make
that change (and do some testing) tomorrow.

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

Add the keystore to svn as well. That way, the test should always work.

> Forgot that you need to read() after startHandshake() - just cut&pasted the
> code from
> JsseSupport and it worked.

Mark


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




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


Mime
View raw message