2009/11/9 Mark Thomas <ma...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
