IETF Logo Mail Archive

Re: [TLS] SCSVs and SSLv3 fallback

Adam Langley <agl@google.com> Mon, 08 April 2013 15:10 UTC

Return-Path: <agl@google.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CC121F9816 for <tls@ietfa.amsl.com>; Mon, 8 Apr 2013 08:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.977
X-Spam-Level:
X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yss8Y3hJDHp9 for <tls@ietfa.amsl.com>; Mon, 8 Apr 2013 08:10:56 -0700 (PDT)
Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) by ietfa.amsl.com (Postfix) with ESMTP id 805E221F9798 for <tls@ietf.org>; Mon, 8 Apr 2013 08:10:49 -0700 (PDT)
Received: by mail-ie0-f173.google.com with SMTP id 9so7095210iec.4 for <tls@ietf.org>; Mon, 08 Apr 2013 08:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nUybnuUN85QTNOM1RxWdLeCIq9mAv7Ry0JxZaYHdVoY=; b=HlRlj2HreDkUHwIVzy9yb/TjEH2bW4OJF8o4H5I5bSTMTrBw+qGSp36et9XSsKlOee 8xWsV68XKLWxaVmxw8wPN4Q+TyPQIS/HVeXr64tfQswdf91KxDCEeYeg0Oj9p/X5ylcR Onb8DoEl9clJ9rGsUhj3nK5e13pd76oVZFJY9JYxh66RzekfbTvqOt6+IN9TX5AtpWSv 2fQtxew9UMWOnl9314dxP+zgN/2nBwCbuDFjVBugN8x7uItyQXo+i6617lPHKH7BLFp/ t6LJurrr0sdlDaTr4FM8SNn/Y66giQKb0FWXkqpzcJV3BIQBqTzEwtZDao3Y8AlOkcMB VL8g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=nUybnuUN85QTNOM1RxWdLeCIq9mAv7Ry0JxZaYHdVoY=; b=bh4g/fsyjwZQ+6IlClAoA2pyTZT1Z9nmSbZkY/59O/SxOSNK8BLbZdWldT40ElwRjX EyV453tvGoeB+v6/JNkBO2V0egUR7tSxmUnTFio2OtiT2PR7TtGT06lJjSkQG0eXVwSs 5vofrOG+txlSHD3XYOQd7kM5Mbi43lZ5PQNx/gL2d3zmJ8hU7JHooxFzLy+WjsUFdUVf +a/mp1/G3UyhQua4mm4Uv3Wkldvc2LnHOaKj/9/piLAuZJkK9L2WG1Kv27mV6pVZYlVB U3KQ4HvSDnlY+3Q/SIPZ9u9j56u1Vp2r8oOjSumn3Ckz5uK8EPIa8nnvxQC7Dl3Ua8XN eN4A==
MIME-Version: 1.0
X-Received: by 10.50.150.167 with SMTP id uj7mr7345070igb.1.1365433843109; Mon, 08 Apr 2013 08:10:43 -0700 (PDT)
Received: by 10.231.229.6 with HTTP; Mon, 8 Apr 2013 08:10:43 -0700 (PDT)
In-Reply-To: <m2a9permge.fsf@localhost.localdomain>
References: <CAGZ8ZG0i4-ZDPu=O1+Qy1DJ8oV80_eMz5J9NZrn2UC1-zYu4Sw@mail.gmail.com> <m2a9permge.fsf@localhost.localdomain>
Date: Mon, 08 Apr 2013 11:10:43 -0400
Message-ID: <CAL9PXLzREVyKM6_iX8zm3St8Fq=Ts0mPN5T9hn9ymbYnjYr98g@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Geoffrey Keating <geoffk@geoffk.org>
Content-Type: text/plain; charset="UTF-8"
X-Gm-Message-State: ALoCoQlOJJCcHQbCJOooB3UQI9RA9vHssAKoyoaIuOakUAqGhZrsxvnxVwJUAx7G08J/67fNmtfNAB4n2FKOxtEwCVB/dkrrqD9gkKSqT7u2SC3i/dpw6/Qm/xB6TX2qnD5UL7m/aMaxAZpMHgWprLg8KxmxINB7b0/DycorBtEUUoUtMG15gX3lbQuQyb71shYjU7rLo6Bm
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] SCSVs and SSLv3 fallback
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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, 08 Apr 2013 15:10:58 -0000

On Thu, Apr 4, 2013 at 5:54 PM, Geoffrey Keating <geoffk@geoffk.org> wrote:
> The name of one firewall which is confirmed to do this would make it a
> lot more convincing...  It's likely that some TLS connections failed
> due to packet loss or a busy server and so the 'fallback' was a
> mistake.

NetASQ devices certainly did do it, at least in some configurations.
Hopefully that has been fixed since I contacted them about it, but I'm
sure that not every customer has updated etc.

At the moment Chrome has a two-step fallback: TLS 1.1 -> TLS 1.0 and
then to SSLv3. From Chrome to Google (i.e. TLS 1.1 capable endpoints)
we see 0.1% of connections doing both fallbacks and then connecting
successfully. Of course, it is possible that this is due to transient
networking issues, but it seems like a rather high number for that.
(In contrast we see 0.3% doing just the first fallback)


Cheers

AGL

v2.23.0 | Report a Bug | By Email