On Mon, Nov 9, 2009 at 8:04 AM, Konstantin Kolinko <knst.koli...@gmail.com>wrote:
> 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? > 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. 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
