User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.69 Safari/537.36

[Inlining attachment as text comment] Don't send encrypted extensions (NPN) for untrusted server certificates ----------------------------------------------------------------------- We recently submitted a bug to Chrome and I'm copying some of it here, because a similar (but less severe) issue exists in Firefox. The full Chrome bug report is here: https://code.google.com/p/chromium/issues/detail?id=305951 It mainly refers to Channel ID, which Firefox does not support yet, but the underlying issue applies to all privacy features that use the TLS NPN extension's Encrypted Extensions format. Firefox enables the TLS NPN extension (notably used by SPDY/3) implemented in NSS. In this extension, the client and server offer a set of NPN protocols in their hello messages, and then the client chooses a protocol and sends it in a NextProtocolMessage. To protect the privacy for the client's choice (say if the protocol was Tor), NPN requires the NextProtocolMessage to be encrypted using a new encrypted extensions message format, so this message is sent after the Client CCS and before the Client Finished. (A similar encrypted message format is used by the Channel ID and Origin-Bound-Certificate extensions, but neither are enabled by Firefox). However, these privacy protections are completely broken by the way Firefox deals with untrusted server certificates, leading to active network attacks that can decrypt the encrypted handshake message. During a TLS Handshake, if Firefox receives an untrusted server certificate (e.g. a self-signed or expired cert or cert for another domain); it does not abort the Handshake. It will in fact complete the Handshake and then send a fatal alert to close down the connection before it presents the suspicious certificate to the user. This means that any encrypted extensions will in fact be sent encrypted under the untrusted server's public key and can be decrypted by it. Notably that this is not a downgrade attack, it is a failure of server authentication. Even if the client uses TLS 1.2 with the strongest available ciphersuite, the untrusted server will be able to obtain the channel ID. Proof of concept ---------------- To try it yourself, set up an openssl server with a self-signed cert and NPN enabled, modify your /etc/hosts to point google.com at the server's IP address. Open google.com on Chrome. Even though this server will not have google.com's certificate, Chrome will reveal the user's NPN message for google.com to the attacker. Impact ------ Currently, NPN is only used to negotiate fairly innoccuous details about which version of HTTP/SPDY to use. In the future, however, new extensions like Channel ID may use NPN-like encrypted extensions to send sensitive data before the handshake is complete. In these cases, Firefox's handling of bad server certificates will break any privacy guarantees. For now, I guess this is sec-low. But I have still marked this bug as high-security, since a similar bug in Chrome has severe consequences. Fix --- In a handshake where the server certificate has not been verified, either abort the Handshake, or else disable NPN and related extensions that rely on encryption. If, for interoperability, you do need to send the encrypted messages, send dummy messages in their place

This bug is really about Chromium's extensions that aren't in NSS. We know that we're sending NPN (just the protocol negotiation part) on an as-yet-unauthenticated connection; there's even a comment in the source code pointing it out. It would be better to stop doing it for NPN but that would mean that none of the handshake optimizations we do would work. Also, other browsers (IE and Chrome) are leaking this information in cleartext in the ClientHello via the ALPN extension already.

Google's bug is opened. Opening this one. Perhaps this should be RESOLVED INVALID given that NSS doesn't support ChannelID or the encrypted client certificate extension?

We don't allow to disable NPN and will remove the code soon.

(In reply to Franziskus Kiefer [:fkiefer or :franziskus] from comment #4) > We don't allow to disable NPN and will remove the code soon. We don't allow to enable NPN obviously.