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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
