Konstantin Kolinko 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/
Noted. I'll get the notice out. > 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. Hmm. Interesting. I need to do some testing :) I'll add something along the lines of "We are currently evaluating a number of possible work-arounds prior to a protocol fix becoming available. Discussion is happening on the dev list and any significant developments will be posted to the users@ and announce@ mailing lists. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
