[TLS] An SCSV to stop TLS fallback.
Adam Langley <agl@google.com> Mon, 25 November 2013 23:28 UTC
Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22491AE0CC for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8dn4shUEKEE for <tls@ietfa.amsl.com>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7C01AE0BB for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
Received: by mail-vb0-f53.google.com with SMTP id g10so3222890vbg.26 for <tls@ietf.org>; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=jsnQxZvGMiz8/WTv/lHGW5DuBrzNMV0prfRy6K5hbkqOsiFwyrJbzFGP0YPL1VeFE6 HAb6iFtBVIgLojYaKdo8ubKjKGwqhSps6fSbL+Fd773aHzV22ttJP4y9P5m3VnOxiHXX kKaiI9NcI1noVahK+k7ttKJaaxSf/Lv7MZcmqLAXTl1TD4ic8Iw1HFt6U+VX3yO7KPrk iwR/wNRX+La+Wov1gi6aeK8FaF0VjRFkoBAvHe0dvTGa0sylKAtvfLjXcafXlISaokmR NrlTaPLYw/4+l9EtbdrHoj5cveQjSCHk4ykgAfIdfdcovWBxtWfqwE+YC1jxIZNAtMZ2 UfzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=pdmMIPEcBqAHMVseXTL03PjbQGYiewTSfajHImFiO5w=; b=lOJTQt7vvZQQz4e2aNZS2/+kuissaLZFXleIwu58oaw8gPtS1f7SdOk9/7VeC+gNvb hZAqMDw1edrwwJckOIz+HK+o+4sWywNxa3znvg7ZcN40tq3/GYQil7C1BaSFUIKz6AYv qLi2S58FtLctkGg49e2mzpiVWgItXrtLLA8/+FQwNPDNnuJR9qDLSaJbae576KCH60SD g/MlHlWfMCDwbBImDvFo2gYKiQOK+35pmUD0cZGrxjWrBK3JYXRKJ02U9fgr0roPg3Fa lYgZqYz3ZMYWUgFVAJqaWVyltDxg8wALfXzT6AUcJ0/JYf5/rp023FEDzm8DP9lmcpSs BzDA==
X-Gm-Message-State: ALoCoQnJOQ+UFHktYT1IGR9iBMKdXTtyXX2CZarzuAAItom9agbuC7B+i/F6QJ9dCBsy83MeQoZp5lJSnUphCbXYSI11vOsgsw0sfkFMyjhGUZzDZD8+QFi7EcIaj+V1EJK2eDeNI2+0uD/B92wSXDoS6j/s3psi7gaq6zE7CBAPECdUxNYdh+GmjZmhE/bBCZrtBkr8e+s2
X-Received: by 10.52.98.99 with SMTP id eh3mr2807040vdb.29.1385422098224; Mon, 25 Nov 2013 15:28:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.52.100.40 with HTTP; Mon, 25 Nov 2013 15:27:58 -0800 (PST)
From: Adam Langley <agl@google.com>
Date: Mon, 25 Nov 2013 18:27:58 -0500
Message-ID: <CAL9PXLzWPY5o2SeV=kUPWxznkw+3cmpbMpYifCebfqd48VW9UA@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Subject: [TLS] An SCSV to stop TLS fallback.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Nov 2013 23:28:20 -0000
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 connection. 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. Cheers AGL
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Andy Wilson
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Trevor Perrin
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Trevor Perrin
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Brian Smith
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Jack Lloyd
- Re: [TLS] An SCSV to stop TLS fallback. Manger, James H
- Re: [TLS] An SCSV to stop TLS fallback. Wan-Teh Chang
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Wan-Teh Chang
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Marsh Ray
- Re: [TLS] An SCSV to stop TLS fallback. Douglas Stebila
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. James Cloos
- Re: [TLS] An SCSV to stop TLS fallback. Yngve N. Pettersen
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Marsh Ray
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Adam Langley
- Re: [TLS] An SCSV to stop TLS fallback. Daniel Kahn Gillmor
- Re: [TLS] An SCSV to stop TLS fallback. Brian Smith
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Watson Ladd
- Re: [TLS] An SCSV to stop TLS fallback. Martin Rex
- Re: [TLS] An SCSV to stop TLS fallback. Yaron Sheffer
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Yaron Sheffer
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Manuel Pégourié-Gonnard
- Re: [TLS] An SCSV to stop TLS fallback. Ralf Skyper Kaiser
- Re: [TLS] An SCSV to stop TLS fallback. Bodo Moeller