Re: [TLS] Thoughts on Version Intolerance
Hubert Kario <hkario@redhat.com> Mon, 18 July 2016 13:12 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 1617B12DAEC for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 06:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.189
X-Spam-Level:
X-Spam-Status: No, score=-8.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 oD0piWYaJ7uz for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 06:11:56 -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 50BDB12DA39 for <tls@ietf.org>; Mon, 18 Jul 2016 06:08:10 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 DA943C0005D0; Mon, 18 Jul 2016 13:08:09 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (dhcp-0-107.brq.redhat.com [10.34.0.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u6ID88wt026261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Jul 2016 09:08:09 -0400
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Mon, 18 Jul 2016 15:08:03 +0200
Message-ID: <1735315.hXCMA8agXV@pintsize.usersys.redhat.com>
User-Agent: KMail/4.14.10 (Linux/4.6.3-300.fc24.x86_64; KDE/4.14.20; x86_64; ; )
In-Reply-To: <20160718130843.0320d43f@pc1>
References: <20160718130843.0320d43f@pc1>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart2311106.RTmiUEvLIW"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 18 Jul 2016 13:08:10 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FKFPX1NazH3Dak-AbRYUG6TiEP8>
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: Mon, 18 Jul 2016 13:12:01 -0000
On Monday 18 July 2016 13:08:43 Hanno Böck wrote: > * There don't seem to be any straightforward tools that test for > version intolerance. The SSL Labs test does detect version > intolerance, but it's limited to public facing https servers and it > doesn't seem to detect some of the weirder variations (as described > above). There's also a test in Hubert Kario's tlsfuzzer, but I've > been unable to get it to work. I tried to create a test myself, but > the results were highly erratic and I'm not sure why. I hope that the updated README helps about this (just pushed the changes), tell me if anything else is missing feel free to send the problems with the test you wrote yourself (but please remember, the note in README applies - it's an alpha, so no API stability guarantees) > * 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. e.g. some servers will just close connection if you send them an SNI name they don't expect 1 - similar to https://en.wikipedia.org/wiki/Christmas_tree_packet > I want to try to work on some of those issues in the near future. > Roughly I'd like to see that we work on a plan to reduce TLS brokenness > in general and in particular - right now as this is an issue affecting > the deployment of TLS 1.3 - Version intolerance. > > Things that I think we could and should do: > * Talk to developers of test tools (sslyze, testssl, openvas, but also > commercial tools etc.) that they include appropriate tests in their > tools and warn about these issues. Also it'd be great if e.g. things > like the google webmaster tools or any other public test tools for > webservers/websites could test for this. +1, especially TLS 1.3 client hello version intolerance should be an outright failure of any TLS test > * Get some data from internet wide scans and make it public. Maybe have > a public shame list of the top X pages breaking TLS. I'm working on it. I'll make the scan data public, but I'll leave the shaming part to somebody else > * In general, more and better detailed documentation of this and > similar issues, also raise this as a potential research topic. +1 again, I think we should do a more "negative" reading of the TLS standard (as in what the peer should do if the other side does not behave as expected) both to specify what alerts should be sent, when, and when such "misbehavior" MUST NOT trigger any failure in the other side -- 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
- [TLS] Client Hello size intolerance Was: Re: Thou… Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Ivan Ristić
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance Yuhong Bao
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Brian Smith
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Peter Gutmann
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Watson Ladd
- Re: [TLS] Thoughts on Version Intolerance Martin Rex
- Re: [TLS] Thoughts on Version Intolerance Benjamin Kaduk
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Watson Ladd
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Kyle Rose
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance Martin Rex
- Re: [TLS] Thoughts on Version Intolerance Hanno Böck
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- Re: [TLS] Thoughts on Version Intolerance David Benjamin
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara
- Re: [TLS] Thoughts on Version Intolerance Hubert Kario
- [TLS] Thoughts on Version Intolerance Hanno Böck
- Re: [TLS] Client Hello size intolerance Was: Re: … David Benjamin
- Re: [TLS] Client Hello size intolerance Was: Re: … Hubert Kario
- Re: [TLS] Client Hello size intolerance Was: Re: … Brian Smith
- Re: [TLS] Thoughts on Version Intolerance Dave Garrett
- Re: [TLS] Thoughts on Version Intolerance Ilari Liusvaara