tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: SSL & Tomcat
Date Mon, 09 Nov 2009 16:04:55 GMT
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?
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