On Sat, Nov 7, 2009 at 8:59 AM, Mark Thomas <ma...@apache.org> 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. > > 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. > IMO we could disable ACTION_REQ_SSL_CERTIFICATE ( with a flag "allowManInMiddle" or completely ). - Keep watch for a Sun update to the JDK that may help address the issue > > Or ask people to switch to tcNative ( i.e. openSSL ) or stop using client cert auth. > 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 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) > - keep an eye on httpd and if they find a work-around, copy it and > release 1.1.18 with renegotiation enabled > > > 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. > > Thoughts? > > How about the cypher suites - I don't think we allow per-context config of allowed cyphers. Also not sure about client-initiated re-negotiation - I guess using a fixed openssl ( do they have a fix ? ) and native would avoid this, otherwise we need to wait for a jsse fix ? Costin
