Re: [TLS] Thoughts on Version Intolerance

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 18 July 2016 13:27 UTC

Return-Path: <ilariliusvaara@welho.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 B9C9512DD2F for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 06:27:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] 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 TJLtKDvPCnb9 for <tls@ietfa.amsl.com>; Mon, 18 Jul 2016 06:27:33 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 81D0312DADE for <tls@ietf.org>; Mon, 18 Jul 2016 06:17:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 192787F3E for <tls@ietf.org>; Mon, 18 Jul 2016 16:17:39 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ZcEWy4OpVGD6 for <tls@ietf.org>; Mon, 18 Jul 2016 16:17:38 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5A4122315 for <tls@ietf.org>; Mon, 18 Jul 2016 16:11:11 +0300 (EEST)
Date: Mon, 18 Jul 2016 16:11:07 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20160718131107.GA12937@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160718130843.0320d43f@pc1>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20160718130843.0320d43f@pc1>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-eOBHbZmvhPoLrPxg9NDVZCzJOY>
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:27:39 -0000

On Mon, Jul 18, 2016 at 01:08:43PM +0200, Hanno Böck wrote:
> Hi,
> 
> Recently both Adam Langley [1] and David Benjamin [2] indicated that
> they expect with TLS 1.3 Browsers will have to bring back the infamous
> version falbacks that caused so much trouble in the past (POODLE etc.)
> to work around broken implementations of the TLS handshake.
> 
> I don't blame browser vendors for this, I can understand their
> reasoning why they think they have to do this, although I don't share
> their opinion. But I think this sheds a light on the sorry state of TLS
> implementations and I want to ask if there's a better way out of this.

Ocassionally browsers also send odd stuff: Recently I ran into a browser
that sends empty session_ticket (or whatever) instead of session_ticket
with empty ticket.

This becomes an issue when the server is pretty hard about TLS hanshake
syntax.
 
> * While there is a lot of scattered discussion about the issue, the
>   pure documentation status of this problem is far from ideal. I am not
>   aware of any good documentation that even describes how exactly
>   version intolerance happens. The "classic" variant seems to be
>   implementations that just close the connection if they are contacted
>   with a version number higher than what they support. But there are
>   also weirder variants where a connection attempt with TLS 1.2 will be
>   downgraded to SSLv3, but a connection attempt with TLS 1.0 will lead
>   to an answer with TLS 1.0. Questions I couldn't easily answer is how
>   connections are terminated (TCP disconnect? TLS alert? Timeouts?)
>   Also I'm not fully aware what the different version numbers
>   (ClientHelo + record version number) mean in context of a handshake
>   and how this influences version intolerance issues.

Things are made even more complicated by the intearction of extension
intolerance: Newer TLS versions might involve new extensions, which
may choke a server, causing extension intolerance to be misdiagnosed
as version intolerance.

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

Also, I have seen at least one server that SSL labs claimed is
intolerant to TLS 1.2, but browser could connect using TLS 1.2
ClientHello without fallback (verified using wireshark).

No real idea what caused that.
 
> 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.

I think SSL labs has had TLS 1.3 intoleance test for a long time. Of
course, it probably doesn't test with what real-world TLS 1.3 ClientHello
looks like...


-Ilari