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 <cos...@gmail.com> wrote: > >> >> On Mon, Nov 9, 2009 at 10:47 AM, Costin Manolache <cos...@gmail.com>wrote: >> >>> >>> 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. >>> >>> >> 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-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: dev-h...@tomcat.apache.org >>>> >>>> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
