Re: [TLS] Thoughts on Version Intolerance

[David Benjamin <[e-mail]>]

If we keep trying to salvage the ClientHello version number, we will be
chasing down intolerance forever. (And I'm honestly bored of doing that.)
I'd prefer we move it to an extension. Either an empty indicator extension
for each version or a single version extension with a list of versions. Or
maybe fake cipher suites if people want it nearer the front.

The important thing is lists can be actively defended. We simply burn a
bunch of u16s and have clients advertise a few random fake ones in every
ClientHello. (I'll be writing something up soon to request that range for
extensions, cipher suites, and curves.) I expect this will make it much
less likely anyone will accidentally ship a server that rejects unknown
versions (or whatever else).

On Mon, Jul 18, 2016 at 1:08 PM Hanno Böck <[e-mail]> 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.
>
> Let me quickly summarize how I see the situation:
> * The issue has been known for a long time. I found a document from
>   Mozilla [3] from 2003 that describes the core issue.
> * 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.


(I have only seen this once. I'm guessing someone tried to write a filter
which dispatched between two different backends and got it wrong.)


> Questions I couldn't easily answer is how
>   connections are terminated (TCP disconnect? TLS alert? Timeouts?)
>

Connections can get shut off in all kinds of ways. It's buggy servers
getting confused, so the space is pretty open-ended. Various flavors of TCP
disconnects happen, as do alerts. (Not timeouts. Those we can't even
address with a fallback.)


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

The record version number is meaningless in the protocol. It's frozen at
TLS 1.0 for the ClientHello (and, in 1.3, for all records) and not relevant
for version negotiation or fallbacks.

(Note: at least a while ago SSL Labs' intolerance check incorrectly used
the record-layer number. I don't know if this has been fixed. But apart
from that bug, there is no relation between the two.)


> * 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.
> * 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 have quite conclusive data. TLS 1.3 version intolerance is real. The
version negotiation mechanism in draft-ietf-tls-tls13-14 will not be
deployable on the web without a fallback. 2% is a very large number.

I don't want to play the "davidben publicly shames such-and-such site or
vendor" game, which is why I haven't been naming names and reaching out to
people privately. If you prefer a more noisy approach, I didn't do anything
complicated. Just send a 1.2 ClientHello and then swap the number for 1.3
to see if it stopped working.


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

Test suites are great, but I don't think we can rely on people to know to
run them in every corner of the ecosystem.

* Raise this issue with pentesters and tell them they should include
>   this when they're testing devices / products. (Of course this
>   requires to have test tools in the first place.)
> * Get some data from internet wide scans and make it public. Maybe have
>   a public shame list of the top X pages breaking TLS.
> * In general, more and better detailed documentation of this and
>   similar issues, also raise this as a potential research topic.
>
> My hope would be that we can avoid the reintroduction of version
> fallbacks or at the very least reduce the amount of time they have to
> be used. And hopefully at least avoid them altogether for TLS 1.4 or
> whatever comes after 1.3.
>

The only way we're going to do that is by ditching the ClientHello.version
field.


> I'm in Berlin at IETF96 in case people want to discuss this. As this is
> terribly late for this I don't know if this can be included in the TLS
> WG discussion as it's probably already packed with other issues (but I'd
> happily introduce the issue if people want to discuss it).
>
>
> [1] https://www.imperialviolet.org/2016/05/16/agility.html
> [2] https://www.ietf.org/mail-archive/web/tls/current/msg20207.html
> [3]
>
> https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/Notes_on_TLS_-_SSL_3.0_Intolerant_Servers
> [4] https://www.ietf.org/mail-archive/web/tls/current/msg10657.html
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: [e-mail]
> GPG: BBB51E42
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>