Re: [TLS] SCSVs and SSLv3 fallback
"Yngve N. Pettersen" <yngve@spec-work.net> Sat, 06 April 2013 12:14 UTC
Return-Path: <yngve@spec-work.net>
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 2A69421F8E04 for <tls@ietfa.amsl.com>; Sat, 6 Apr 2013 05:14:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 jUOcgbiF1SC1 for <tls@ietfa.amsl.com>; Sat, 6 Apr 2013 05:14:24 -0700 (PDT)
Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id B7B0F21F8CEB for <tls@ietf.org>; Sat, 6 Apr 2013 05:14:23 -0700 (PDT)
Received: from 239.171.251.212.customer.cdi.no ([212.251.171.239]:51110 helo=killashandra.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <yngve@spec-work.net>) id 1UOS0k-00070A-Od for tls@ietf.org; Sat, 06 Apr 2013 14:14:22 +0200
Content-Type: text/plain; charset="iso-8859-15"; format="flowed"; delsp="yes"
To: "tls@ietf.org" <tls@ietf.org>
References: <CAGZ8ZG0i4-ZDPu=O1+Qy1DJ8oV80_eMz5J9NZrn2UC1-zYu4Sw@mail.gmail.com> <op.wu1f2u2n3dfyax@killashandra.invalid.invalid> <CAGZ8ZG1JzgnCNqfPueKr3wrvMzZKUi7mfvcAdRc-NnCDr33aLg@mail.gmail.com> <515F428E.2010900@gnutls.org> <CAGZ8ZG2OqLz8NymWzR0WNWsHz7qHLA+8eq95WFTLVFGaTK=RCA@mail.gmail.com> <D4CC5248-B1F1-498E-8058-5E17BADB3CE6@vpnc.org> <CAGZ8ZG2uvKs8-Sn9bvQyaP9t_E3BhkZFoi7Sq9wbxaHNpf_NDg@mail.gmail.com> <op.wu3cctbc3dfyax@killashandra.invalid.invalid> <CAGZ8ZG3H6wPnLZE3CkBGHMiMXvdA-VBM911t+tzPqW5ggJr2PA@mail.gmail.com>
Date: Sat, 06 Apr 2013 14:14:06 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: "Yngve N. Pettersen" <yngve@spec-work.net>
Message-ID: <op.wu4b9sxq3dfyax@killashandra.invalid.invalid>
In-Reply-To: <CAGZ8ZG3H6wPnLZE3CkBGHMiMXvdA-VBM911t+tzPqW5ggJr2PA@mail.gmail.com>
User-Agent: Opera Mail/12.15 (Win32)
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: Sat, 06 Apr 2013 12:14:26 -0000
On Sat, 06 Apr 2013 06:41:33 +0200, Trevor Perrin <trevp@trevp.net> wrote: >> The danger is that by using an SCSV we might "fix" the problem for one >> group >> of users, and completely break SSL/TLS for another group of users > > Suppose the SCSV is only allowed in the specific case of an SSLv3 > fallback where an extension response is required or the connection > will fail (due to a requirement for TACK, CT, or OCSP). > > In this case, it can't break anything because the connection is > already going to be broken. It's not guaranteed to work, but there's > evidence it might. > > Does that address this concern? No, it does not. The reason it does not, is that once the client have fallen back to SSL v3 due to version and/or extension intolerance in the server and/or the middleboxes you can either use a plain SSL v3 or a SSL v3 with the proposed SCSVs. Assuming a plain SSLv3 does not work, then the SCSV will not work either. OTOH, if the the plain SSLv3 works OK, we do not at present know if the SCSV variant will work in all cases. even if the SCSV is passed through, we do not know if the Server Hello extension will be passed through on the way back. So, using an SCSV in the SSL v3 handshake do risk breaking a handshake that would otherwise have completed. I have no idea how likely that problem is, but as Nikos pointed out, this is trying to accommodate bugs in implementations, but we don't have a complete list of the bugs that have been created in these implementations. >> Bottom line: Assume that Murphy's Law applies; if something can be done >> wrong, then somebody will do it wrong. And in terms of these >> middleboxes, >> somebody have, but we don't know how many ways they have done it wrong. > > Sure. What data do we have? > > Does the estimate of 1/1000 connections between (TLS-capable clients > and servers) getting an SSL3 fallback seem right to you? Actually, the numbers I have been informed of is that the number of completed connections forced to SSLv3 is less than half that. The number of affected renego patched *servers* in my sample is in the 0.2% range IIRC, but number of server does not translate to actual usage in number of connection by users. The much lower fraction of downgraded connections indicate that the servers I've detected are not frequently accessed. (BTW, the total number of intolerant servers is about 1.5%, most of them not renego patched). > Do you have any idea how much of that is general network problems vs. > middlebox problems? All the discoveries about this problem have been made by Google. I know Google was considering doing some tests to try to ferret out how much of the problem was due to middleboxes or the servers, but I do not know if they have done so yet, or what the results were, if they did. -- Sincerely, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Hanno Böck
- Re: [TLS] SCSVs and SSLv3 fallback Geoffrey Keating
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Joseph Birr-Pixton
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Nikos Mavrogiannopoulos
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Paul Hoffman
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Nikos Mavrogiannopoulos
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Adam Langley
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Trevor Perrin
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Yngve N. Pettersen
- Re: [TLS] SCSVs and SSLv3 fallback Martin Rex
- Re: [TLS] SCSVs and SSLv3 fallback Yoav Nir