Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Wed, 20 July 2016 09:20 UTC

Return-Path: <hkario@redhat.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 5410A12D0D3 for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 02:20:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.209
X-Spam-Level:
X-Spam-Status: No, score=-8.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Z2QB4HHEVqdG for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 02:20:53 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B2F12B004 for <tls@ietf.org>; Wed, 20 Jul 2016 02:20:52 -0700 (PDT)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 051D17F7BB for <tls@ietf.org>; Wed, 20 Jul 2016 09:20:52 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6K9Ko8A018211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 20 Jul 2016 05:20:51 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 20 Jul 2016 11:20:46 +0200
Message-ID: <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com>
User-Agent: KMail/5.2.3 (Linux/4.6.3-300.fc24.x86_64; KDE/5.23.0; x86_64; ; )
In-Reply-To: <1735315.hXCMA8agXV@pintsize.usersys.redhat.com>
References: <20160718130843.0320d43f@pc1> <1735315.hXCMA8agXV@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3020828.KfZDmd1KME"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Wed, 20 Jul 2016 09:20:52 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bOJ2JQc3HjAHFFWCiNTIb0JuMZc>
Subject: Re: [TLS] Thoughts on Version Intolerance
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 20 Jul 2016 09:20:56 -0000

On Monday, 18 July 2016 15:08:03 CEST Hubert Kario wrote:
> On Monday 18 July 2016 13:08:43 Hanno Böck wrote:
> > * We don't have good data on the issue. The latest numbers I could find
> > 
> >   came from Ivan Ristic in 2013 [4], and from David Benjamin we know he
> >   considers the problem to be large enough that version fallbacks are
> >   inevitable. That's far from good data. We also don't seem to have any
> >   public list of affected vendors, devices and webpages.
> 
> I'm running a test against the Alexa Top 1 million /right now/ using this
> code:
> https://github.com/jvehent/cipherscan/pull/109
> 
> In general it's a rough check, i.e. it's only a check for client hello
> version intolerance, irrespective of record layer version, ciphers or
> extensions (it sends multiple probes, based on different clients and
> then modified)
> 
> I've also added an Xmas-client hello message[1] that aims to trigger as
> many intolerancies as possible, but it's mostly just to single out
> some weirder servers.

So I have partial results after scanning around 14 000 domains.
The scanner was able to connect to 12 606 hosts that presented unexpired
certificates signed by CA's in Mozilla root program.

Of those:
93% support TLSv1.2 protocol (11807)
a single one is intolerant to TLSv1.2 Client Hello
3.7% (469) are intolerant to TLSv1.3 Client Hello
4.4% (556) are intolerant to TLSv1.4 Client Hello

(by intolerant, I mean, I was not able to connect to them with any hello
message that looked like an IE, Chrome or Firefox Client Hello with just
version changed or additionally some or all extensions removed)

at the same time, 15.5% (1965) are intolerant to an "Xmas tree" Client
Hello (one that includes many ciphers, few TLSv1.3 key shares, etc. bringing
its size to something like 2800 bytes)
49% (6240) are intolerant to a Client Hello with no extensions but
big number of ciphers that bring its size to 16388 bytes)
91.5% (11539) are intolerant to a Client Hello with no extensions
but a number of ciphers that bring it well above single record layer limit
(16.5KiB)

so it looks to me like while we may gain a bit of compatibility by
using extension based mechanism to indicate TLSv1.3, it looks to
me like the 1RTT mechanism will uncover more bugs like the one in F5
accelerators (the 256-512 byte black hole)
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic