On Wednesday 01 June 2016 22:29:06 David Benjamin wrote: > In case folks hoped we could bump the ClientHello version without > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance > very much exists. (Maybe we should just give up on > ClientHello.version and use an extension? Extensions have rusted > less.) > > I picked a large list of top sites and tried connecting to them. Just > under 2% of them could handle a TLS 1.2 ClientHello, but not the same > ClientHello with the version switched to 1.3 (no other changes, so I > haven't tested a real 1.3 ClientHello). They're not unknown hosts > either. I expect if you probe any top site list, you'll very quickly > find some.
there are also servers which choke on large extensions (say 4096 bit DH client key share with 384 bit ECDH key share), so avoiding the bump in version number won't solve all the problems either... Speaking of version number, does the text say that a server _MUST_ accept any version higher than the one that is specified in the RFC, but reply with 0x03,0x04 in case it doesn't support any future version of the protocol? It would be nice to have some kind of stick for the broken implementations... -- 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
