On 07.11.2009 17:59, Mark Thomas wrote: > All, > > I was thinking about this on my way back from ApacheCon and we probably > need to get some advice out to users early next week. > > My current understanding is that the MITM attack is triggered by a > renegotiation.
Yes, client side initiated (AFAIK the client can decide to do this at any time) and server initiated (most likely case is requiring client certs for some parts of the content served by the host, or varying cipher configuration on one site. > On this basis I suggest something along the following lines: > > SSL using JSSE (BIO and NIO connectors) > - Don't use SSL configs that require renegotiation. i.e. SSL config > should be the same for the entire host. Sites that require SSL in some > places and SSL + CLIENT-CERT in others will require reconfiguration. > Sites that require SSL for some parts should be OK. Except for client initiated renegotiation :( > - Keep watch for a Sun update to the JDK that may help address the issue Plus other vendors. > SSL using tc Native > - tcnative does not support renegotiation > (https://issues.apache.org/bugzilla/show_bug.cgi?id=46950) so for now > users of tc native with SSL should be OK We need to test whether existing versions of Tomcat (with or without tcnative) support client side initiated renegotiation. I can do it for the tcnative case. The test (not a full MITM scenario but only a reneg test) uses the openssl command s_client which can do reneg when typing "R". My gut feeling says with tcnative we will support reneg and it will be transparent to Tomcat. If that turns out to be true, we would need to react w.r.t. tcnative (see below). > We also need to think about what to do with tc native. Maybe something like: > - release 1.1.17 with binaries built with 0.9.8l (so renegotiation is > disabled) Yes, disabling is fine for the moment, because it doesn't break existing functionality. We should also add a comment about it in docs somewhere, so that users building themselves using their OS supplied outdated OpenSSL have been warned. > - keep an eye on httpd and if they find a work-around, copy it and > release 1.1.18 with renegotiation enabled +1 and making 1.1.18 a dependency for 6.0.21 and 5.5.whatever. > For now, I'm not proposing any changes to the docs although we may want > to put a summary of the advice - once agreed - on the security pages. +1 In summary the aspects for tcnative based SSL are A) how to optionally fully disable all reneg - OpenSSL 0.9.8l - Breaks some future configs, but maxes on security - Users need to update binary tcnative to 1.1.17 or rebuild their older version against new OpenSSL B) how to disable client initiated reneg - Try porting httpd fix to tcnative - Will need new tcnative C) how to fix config, so that there's no server initiated reneg - Needed in Addition to B) D) how to fix reneg code, so that server initiated reneg gets safe - Might need proposed SSL extension, so newer OpenSSL version and possibly changes to tcnative Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
