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:

1. Why TLS 1.3 isn’t there yet
2. Short news

Why TLS 1.3 isn’t there yet

Deployment of TLS 1.3 is currently blocked by faulty middlebox devices. In theory, the protocol has been deemed ready; the latest draft 21 of TLS 1.3 was published in July, and it’s been in “Last Call” state for a while.

As Eric Rescorla reports in the TLS working group, a significant number of connection failures have been observed in experiments carried out by Google and Firefox. The source of the failures seems to be middleboxes that try to analyze traffic and block packets that don’t look like known protocol messages.

Details are scarce at this point, and no vendors have been named. The only known case of a vendor failing at TLS 1.3 was due to a bug in Blue Coat devices, as mentioned in our January newsletter.

However, it seems that changing TLS 1.3 in slight ways that make it look more like TLS 1.2 may make it possible to bring the failure rate down to an acceptable level. How these changes look is unclear, as it hasn’t been discussed in public.

Once again, it seems faulty devices make deploying a new protocol harder. This isn’t new. The deployment of previous TLS versions was seriously hampered by so-called version intolerance. Fallbacks implemented by browsers in the past have subsequently led to security vulnerabilities like POODLE. In TLS 1.3, a new version negotiation mechanism was implemented, and the GREASE mechanism was introduced to prevent such issues in the future.

Short news

• KRACK is an attack against the Wi-Fi encryption protocol WPA2. Although not directly related to TLS, many have pointed out that widespread and proper usage of TLS and HTTPS can mitigate the effects of KRACK. Independent of protocol vulnerabilities, the confidentiality features of WPA2 are questionable for Internet connections because they only encrypt the first hop.
• The ROCA attack is a severe weakness in the RSA key generation of cryptographic devices produced by Infineon. It affects various products. Notably, the vulnerable implementation has been certified by both FIPS and Common Criteria. Only a few TLS certificates have been affected, however.
• The DUHK attack is a weakness in the random number generator ANSI X9.31. It uses a key that’s crucial for its security; in many products, this key has been hardcoded. Notably, researchers found 25,000 vulnerable Fortinet devices connected to the Internet. The researchers found these weaknesses by analyzing FIPS certification documents, making it the second severe vulnerability this month that was in government-certified crypto products. The vulnerability affects IPSEC and TLS connections.
• A blog post explains how cross-site scripting can be achieved through the content of a certificate request.
• Google will start adding some of its top-level domains (TLDs) to the HSTS preload list, meaning all domains under those endings will only be accessible via HTTPS on modern browsers. This includes the TLDs .foo and .dev. Mattias Geniar points out that this can cause problems for people who use .dev for local testing hosts. Although .dev is commonly used for that purpose, it’s never been reserved for it. The .test ending should be used for such cases instead. However, we could argue that having local untrusted test domains is a bad idea anyway and that users should just use normal domains with valid certificates.
• Filippo Valsorda explains the security risks of TLS session tickets in TLS 1.2 and how they compromise forward secrecy. TLS 1.3 will have a better mechanism of preshared keys that will replace session tickets.
• Mozilla’s NSS library is using a new GCM implementation that’s faster than the previous one and constant-time. We mentioned Mozilla’s efforts to formally verify parts of that new implementation in last month’s newsletter.
• Two attacks on EdDSA have been presented. One uses a side-channel attack on electromagnetic leakage; the other uses fault-injection attacks via Rowhammer. In both cases, the deterministic nature of EdDSA makes it vulnerable. The fact that EdDSA is deterministic previously has been an argument for it being more secure because it doesn’t require a reliable random number generator. The older ECDSA algorithm is nondeterministic in its original variant, but failures of the random number generator can have catastrophic consequences.
• A research team tried to use differential fuzz testing on TLS handshakes by comparing the behavior of different implementations. It found several implementation bugs and a serious vulnerability in MatrixSSL.
• Let’s Encrypt announced the availability of an Apache module that allows web sites to automatically get certificates with the ACME protocol. However, it still comes with some limitations. It can’t be used with an unpatched Apache release yet, and it requires manual server restarts.
• Troy Hunt has written a blog post outlining six steps to HTTPS for your webpage.
• The next version of Android will support DNS over TLS.
• Last month, we reported on the new CAA feature and that many certificate authorities failed to properly implement it early on. A new test of CAA corner cases still found some smaller violations of certificate authorities, but no major ones.
• Tumblr now supports HTTPS for custom domains.
• Akamai explains in a blog post that in its measurements, 99.6 percent of clients support SNI. Akamai notes that the remaining ones will have to hurry supporting it, because it’s required more often these days.
• An article in the Vancouver Sun mentions that the Canadian government has plans to require HTTPS for government web pages.
• NSS 3.33 fixes a use-after-free vulnerability in the TLS 1.2 handshake.
• Researchers from Google analyzed HTTPS errors in browsers and their root causes in a paper for the upcoming CCS conference.
• The author of this newsletter now tweets cases of insufficient HTTPS support from the @nomorehttp Twitter account.
• A new draft to add surveillance / visibility capabilities to TLS 1.3 has been proposed on the TLS working group list. Not surprisingly this led to a long thread with many people strongly opposed to such an extension to TLS.
• Chrome 62 adds warnings for unprotected HTTP pages that use forms to enter data. However right now it’s only enabled for a small fraction of users by default.
• TLS-N is a proposed extension that allows non-repudiation for TLS connections. This means a party of a TLS connection using that extension can not deny that some data is transmitted, as it’s cryptographically signing the content.
• A master’s thesis is analyzing the cryptographic support in the Rust ecosystem.
• Chrome has announced plans to remove support for HTTP Public Key Pinning (HPKP). This is a result of many discussions lately about the problems with HPKP, particularly that it can cause people to accidentally make their site inaccessible by losing all pinned keys.