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/