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.
In this issue:
- Does TLS have to change constantly to make it future-proof?
- Short news
Does TLS have to change constantly to make it future-proof?
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).
Short news
- A TLS 1.3 workshop has been announced for the Crypto 2018 conference on August 19.
- Lin Clark from Mozilla explained DNS over HTTPS in a blog post.
- The hash-based signature scheme XMSS has been specified in RFC 8391. XMSS is assumed to be postquantum secure, but it’s a stateful scheme and thus often not a drop-in replacement for existing signature schemes.
- A buffer overflow has been found in the EAP-TLS implementation of pppd.
- OpenSSL published a security advisory about a denial of service vulnerability with Diffie-Hellman parameters.
- NCC Group has published research about memory cache side-channel attacks against ECDSA and DSA. Libgcrypt has published a security fix in response to the research.
- Let’s Encrypt supports a new domain validation method using the ALPN mechanism of TLS. A draft for an RFC has also been published.
- Digicert announced that it is leaving the CA Security Council (CASC). The CA Security Council is an industry group representing certificate authorities. The Digicert blog post indicates that the company had disagreements over the focus of the CASC and particularly about Extended Validation certificates.
- A draft for an RFC proposes deprecating the old TLS versions 1.0 and 1.1.
- For the upcoming Black Hat conference, a talk about a new CPU side-channel attack called TLBleed was announced. The Register has some background.
- Starting in July, the PCI-DSS credit card standard requires disabling TLS 1.0.
- Scott Helme has written about how Certificate Transparency logs can be used to spot phishing.
- Google will automatically redirect links via ads on Google search to HTTPS if the site supports it.
- Two projects started providing JavaScript functionality to communicate with Certificate Transparency logs: ctutils and CTjs.
- Eric Lawrence noticed that Microsoft changed its behavior with EV certificates. The green EV indicator is only shown if SmartScreen (an anti-phishing feature from Microsoft) is enabled.
- The EFF restarted its STARTTLS Everywhere project, via which it maintains a list of configurations of SMTP servers with valid certificates.
- Hardenize supports validating the Expect-CT header.
- The standards for MTA-STS (TLS certificate validation for email servers) and SMTP-TLSRPT (reporting about TLS failures) are approved and soon will have RFCs. Hardenize explains MTA-STS in a blog post and introduces checks for it.
- Firefox 61 enables support for the latest draft version of TLS 1.3 by default.
- We’re almost certain that we’ll be able to announce TLS 1.3 in the next newsletter. Rumors say it’ll be RFC 8446.