Re: [TLS] Thoughts on Version Intolerance

Hubert Kario <> Mon, 18 July 2016 13:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1617B12DAEC for <>; Mon, 18 Jul 2016 06:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.189
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oD0piWYaJ7uz for <>; Mon, 18 Jul 2016 06:11:56 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 50BDB12DA39 for <>; Mon, 18 Jul 2016 06:08:10 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA943C0005D0; Mon, 18 Jul 2016 13:08:09 +0000 (UTC)
Received: from ( []) by (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 <>
Date: Mon, 18 Jul 2016 15:08:03 +0200
Message-ID: <>
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
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 18 Jul 2016 13:08:10 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] Thoughts on Version Intolerance
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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

> 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

Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic