Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <hkario@redhat.com> Wed, 20 July 2016 12:47 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 F1D5C12D6AA for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 05:47:07 -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 SO4M3lIplPwE for <tls@ietfa.amsl.com>; Wed, 20 Jul 2016 05:47:05 -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 44F3612D58A for <tls@ietf.org>; Wed, 20 Jul 2016 05:47:05 -0700 (PDT)
Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (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 AA777796F4; Wed, 20 Jul 2016 12:47:04 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6KCl25s005131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2016 08:47:03 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 20 Jul 2016 14:46:51 +0200
Message-ID: <12453699.ubOGoNYMcu@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: <20160720105736.GA22387@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160718130843.0320d43f@pc1> <2867948.pp4OFeU9TP@pintsize.usersys.redhat.com> <20160720105736.GA22387@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2130319.uUDHmnaQPA"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 20 Jul 2016 12:47:04 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q9G4fuoHVnQGe4lFUZGPezJf8aI>
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 12:47:08 -0000

On Wednesday, 20 July 2016 13:57:36 CEST Ilari Liusvaara wrote:
> On Wed, Jul 20, 2016 at 11:20:46AM +0200, Hubert Kario wrote:
> > 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)
> 
> Wonder how big part of the difference is due to steps (eg. 1024 and
> 2048 bytes) in between and how much is due to the extra extensions or
> cihpers.
> 
> > 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)
> 
> Wonder how much of that is again size thresholds (in Ciphersuites and
> in total ClientHello size) and how much is fragmenting the Client
> Hello to multiple fragments...

yes, that's something I'd like to figure out too, but I was thinking of
using a bisect approach to do it, so it will be more complex to do =>
I won't do this for this month's scan

patches welcome, though :)

-- 
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