28 June 2018
Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Hanno Böck.
The TLS 1.3 standard will soon be finished; however, getting here wasn’t always easy. One problem that accompanied the standardization process was devices assuming old TLS versions. These issues were worked around by protocol quirks—making the protocol needlessly complex, but also deployable. We’ve followed this development in our newsletter. To avoid similar issues in the future, the only option may be to change TLS constantly.
First, there was version intolerance: devices receiving a TLS 1.3 connection would not downgrade to a lower version. To avoid these problems, version negotiation was moved to an extension, and the GREASE mechanism, invented by David Benjamin from Google, was introduced. TLS 1.3 implementations can send a set of bogus version numbers that servers are meant to ignore. The same mechanism can also be used for other fields, like cipher suites.
But version negotiation wasn’t the only problem: middleboxes would assume that TLS packages would follow the format they had used in TLS 1.2 and would break connections if they didn’t. By making TLS 1.3 look more like 1.2, many of these issues could be remedied.
Going forward, the question is how to avoid similar pain in the future. Experience has shown that device makers are unlikely to learn from previous mistakes. Misunderstandings about what you can and can’t do without breaking the TLS protocol are prevalent, and even institutions like the UK government’s National Cyber Security Center seem to be confused.
David Benjamin has proposed something that sounds extreme, but it may be just what’s needed to deploy changes in TLS in the future. The idea is that beside the normal, standardized version of TLS 1.3, there could be temporary variations of it. These would change every few weeks. Some servers and browsers could support them for short amounts of time.
Given the large market share belonging just to Chrome and Google’s own services, it would be unlikely that anyone would deploy devices that break connections between them. It also would be no problem if browsers and web pages couldn’t agree on a temporary TLS version: they can always fall back to standardized TLS 1.3 (at least if both sides implement version negotiation correctly, but this is likely for the implementations participating in such an effort).
This subscription is just for the newsletter; we won't send you anything else.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.