925791 - Don't send encrypted extensions (NPN) when server certificate is untrusted

Status: RESOLVED WONTFIX

(NSS :: Libraries, defect)

Description

[Karthikeyan Bhargavan]

Attachment: npn.txt

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

Comment 1

[Karthikeyan Bhargavan]

[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

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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?

Comment 4

[Franziskus Kiefer [:franziskus]]

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

Comment 5

[Franziskus Kiefer [:franziskus]]

(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.