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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
