Re: [TLS] Thoughts on Version Intolerance

[Hubert Kario <[e-mail]>]

On Monday, 18 July 2016 15:08:03 CEST Hubert Kario wrote:
> On Monday 18 July 2016 13:08:43 Hanno Böck wrote:
> > * 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.

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

so it looks to me like while we may gain a bit of compatibility by
using extension based mechanism to indicate TLSv1.3, it looks to
me like the 1RTT mechanism will uncover more bugs like the one in F5
accelerators (the 256-512 byte black hole)
-- 
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