From thoger at redhat.com Tue Nov 10 17:21:39 2009 From: thoger at redhat.com (Tomas Hoger) Date: Tue, 10 Nov 2009 18:21:39 +0100 Subject: [Mod_nss-list] TLS MITM issues CVE-2009-3555 vs. mod_nss Message-ID: <20091110182139.7a16bd15@redhat.com> Hi! I guess you've already heard of the TLS MITM issue that got reported last week. If not, this bug should have some quick links: https://bugzilla.redhat.com/show_bug.cgi?id=533125 So far, attacks using this flaw were only described for HTTPS. I was wondering what are for fixing / mitigating this in mod_nss. Current effort on NSS field is to provide a mechanism to disable all renegotiation (no renegotiation is the default) before proposed TLS extension is implemented. This will impact mod_nss however, as it needs to do renegotiation in some cases (typically, when client certificate is not needed by default, but is needed for some portions of the site). NSS is going to offer an environment variable to toggle the setting, but renegotiation enabled will also allow client-requested renegotiation, which shouldn't be needed. mod_ssl upstream created an intermediate mitigation patch for the problem that disables client-requested renegotiation: http://marc.info/?l=apache-httpd-announce&m=125755783724966&w=2 It can be used instead of the updated OpenSSL, but will likely be further modified depending on what will be the behavior / default in future OpenSSL versions. It does not fix / mitigate the problem in setups where server-requested renegotiation is needed. Are there any plans for mod_nss modifications to address / mitigate this issue? Btw, can anyone update wiki: http://directory.fedoraproject.org/wiki/Mod_nss#Mailing_List to list correct mailing list archives / info page: https://www.redhat.com/mailman/listinfo/mod_nss-list "Request an account or log in" link only gives me a login page with no create account link. Thank you! th. From rcritten at redhat.com Tue Nov 10 19:07:06 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Nov 2009 14:07:06 -0500 Subject: [Mod_nss-list] TLS MITM issues CVE-2009-3555 vs. mod_nss In-Reply-To: <20091110182139.7a16bd15@redhat.com> References: <20091110182139.7a16bd15@redhat.com> Message-ID: <4AF9B9DA.4060605@redhat.com> Tomas Hoger wrote: > Hi! > > I guess you've already heard of the TLS MITM issue that got reported > last week. If not, this bug should have some quick links: > > https://bugzilla.redhat.com/show_bug.cgi?id=533125 > > So far, attacks using this flaw were only described for HTTPS. I was > wondering what are for fixing / mitigating this in mod_nss. > > Current effort on NSS field is to provide a mechanism to disable all > renegotiation (no renegotiation is the default) before proposed TLS > extension is implemented. This will impact mod_nss however, as it > needs to do renegotiation in some cases (typically, when client > certificate is not needed by default, but is needed for some portions > of the site). NSS is going to offer an environment variable to toggle > the setting, but renegotiation enabled will also allow client-requested > renegotiation, which shouldn't be needed. > > mod_ssl upstream created an intermediate mitigation patch for the > problem that disables client-requested renegotiation: > > http://marc.info/?l=apache-httpd-announce&m=125755783724966&w=2 > > It can be used instead of the updated OpenSSL, but will likely be > further modified depending on what will be the behavior / default in > future OpenSSL versions. It does not fix / mitigate the problem in > setups where server-requested renegotiation is needed. > > Are there any plans for mod_nss modifications to address / mitigate > this issue? Yes, I'm looking into this. I'm not sure I can take the same approach as mod_ssl since I have much less visibility into the SSL handshake with NSS than with OpenSSL. > > Btw, can anyone update wiki: > > http://directory.fedoraproject.org/wiki/Mod_nss#Mailing_List > > to list correct mailing list archives / info page: > > https://www.redhat.com/mailman/listinfo/mod_nss-list Fixed, thanks. > > "Request an account or log in" link only gives me a login page with no > create account link. The wiki has had ongoing spam issues so the frequently lock/unlock new account creation. I guess it is currently locked down. regards rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: From thoger at redhat.com Fri Nov 20 12:42:55 2009 From: thoger at redhat.com (Tomas Hoger) Date: Fri, 20 Nov 2009 13:42:55 +0100 Subject: [Mod_nss-list] TLS MITM issues CVE-2009-3555 vs. mod_nss In-Reply-To: <4AF9B9DA.4060605@redhat.com> References: <20091110182139.7a16bd15@redhat.com> <4AF9B9DA.4060605@redhat.com> Message-ID: <20091120134255.13e669c7@redhat.com> Hi Rob! On Tue, 10 Nov 2009 14:07:06 -0500 Rob Crittenden wrote: > > Are there any plans for mod_nss modifications to address / mitigate > > this issue? > > Yes, I'm looking into this. I'm not sure I can take the same approach > as mod_ssl since I have much less visibility into the SSL handshake > with NSS than with OpenSSL. So do you think SSL_HandshakeCallback-registered callbacks should be insufficient? I do see HandshakeDone callback is already used during the server-initiated rehandshake to track its progress. It is then unregistered when rehandshake is done. What about registering another function instead of the NULL callback? The function that will trigger connection abort when called. Can that be a way or is unlikely to work and is not work more effort? Thank you! th. From rcritten at redhat.com Fri Nov 20 14:42:23 2009 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Nov 2009 09:42:23 -0500 Subject: [Mod_nss-list] TLS MITM issues CVE-2009-3555 vs. mod_nss In-Reply-To: <20091120134255.13e669c7@redhat.com> References: <20091110182139.7a16bd15@redhat.com> <4AF9B9DA.4060605@redhat.com> <20091120134255.13e669c7@redhat.com> Message-ID: <4B06AACF.1030508@redhat.com> Tomas Hoger wrote: > Hi Rob! > > On Tue, 10 Nov 2009 14:07:06 -0500 Rob Crittenden > wrote: > >>> Are there any plans for mod_nss modifications to address / mitigate >>> this issue? >> Yes, I'm looking into this. I'm not sure I can take the same approach >> as mod_ssl since I have much less visibility into the SSL handshake >> with NSS than with OpenSSL. > > So do you think SSL_HandshakeCallback-registered callbacks should be > insufficient? I do see HandshakeDone callback is already used during > the server-initiated rehandshake to track its progress. It is then > unregistered when rehandshake is done. > > What about registering another function instead of the NULL callback? > The function that will trigger connection abort when called. Can that > be a way or is unlikely to work and is not work more effort? > > Thank you! Very clever idea! I think this can be extended a bit too. We really should set the handshake callback to something that returns SECFailure in all cases except where we do a server-initiated renegotiation. So once the initial handshake is completed we shouldn't allow any further handshaking (unless initiated using existing mechanism). I need to check with the NSS guys on a few things but this seems like a very simple way of fixing it. thanks rob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature URL: