An SCSV to stop TLS fallback.
Adam Langley <agl <at> google.com>
2013-11-25 23:27:58 GMT
Sad as it is, in order to work on public Internet all browsers
implement TLS fallback: in the event of a handshake failure they will
retry the connection with a lesser SSL/TLS version.
This means that an active attacker can disable AES-GCM support and,
ultimately, ECDHE if they push the browser back to SSLv3. It would be
good to finally do something about this.
As I've mentioned before, with Chrome 31, we removed support for
falling back to SSLv3 for Google sites. With Chrome 32, we were
planning on removing all fallback for Google sites.
Chrome 31 has been released and saw a fair amount of breakage due to
an anti-virus that (in some configurations) acts as a local MITM and
had bugs. Previously it was depending on browsers falling back to
SSLv3 in order to function at all.
I've since contacted a few other anti-virus and MITM vendors and asked
them about the Chrome 32 change. A couple have informed me that they
will break, at least in some configurations, if Chrome removes all
fallback because they cannot do version negotiation correctly.
I had expected the problems to come in the form of DPI devices sniping
TLS 1.2 connections with injected RSTs rather than MITMs. These
experiments in Chrome 31 and 32 were designed to probe how large a
problem they were. The plan was always to gather information and then
figure out a general solution that avoids having a special case for
Google sites in Chrome.
Since the MITMs are turning out to be the problem, I think the plan
needs rethinking as the general solution need not break MITMs and thus
could be deployed more easily.
Thus I'd like to propose the design of an SCSV with which we can move forward:
In the event that a client is making a fallback connection, it
includes TLS_FALLBACK_SCSV (0x5600) in the list of cipher suites. A
current server which sees this cipher suite in a ClientHello SHOULD
return a fatal alert, inappropriate_fallback (86) and abort the
This will not break MITMs because they will not process the SCSV. Any
vendors that try to support the SCSV while having bugs that need
fallback will find out when things stop working. But that, thankfully,
will be their problem based on the Universal Rule of Users: the last
thing that updated is to blame.
Of course, this doesn't mean that firewalls won't turn out to be a
problem but, at the moment, we can't even figure that out because of
the the broken MITMs. We can't protect MITMed users, but it would be
nice if they didn't ruin it for everyone else.