Bulletproof TLS Newsletter

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 Ivan Ristić.

In the early days of the Internet, no encryption was taking place anywhere, and so it was very easy for those with the right access and means to intercept network traffic. Over the years, the passive monitoring industry grew, although there were also setbacks as SSL and, later, TLS gained popularity.

The extent of the operation became really clear when Edward Snowden released a great amount of confidential information. By that time, a large amount of data was being encrypted, but there was still plenty of metadata that remained in the clear. The Internet Engineering Task Force (IETF) famously declared that pervasive monitoring is an attack and started to work on mitigations.

In the next decade, new mechanisms were being released to hide metadata. First it became possible to encrypt DNS queries, which reveal what websites someone is visiting. Later, Google pushed to deprecate certificate revocation checking via OCSP, which also reveals website names. This left only two places with interesting information: the TLS handshake and the IP address.

One of the goals of TLS 1.3 was to reduce the amount of data that travels in plaintext. This protocol version introduced partial handshake encryption, hiding client and server certificates from view. Unfortunately, the path to encryption of the entire handshake was not clear back then; TLS 1.3 was released without it, but the effort continued.

The first attempt focused on hiding just the name of the server that is being visited. In TLS, this information is transported in the Server Name Indication (SNI) extension, so it was called Encrypted SNI (ESNI). Later, ESNI morphed into Encrypted Client Hello (ECH), providing encryption for the entire handshake.

How does ECH work? To operate, encryption requires keys. In TLS, the very purpose of the handshake is to agree on the keys so that the main content of the connection can be encrypted. This is not a problem that can be solved directly, but we can work around it by publishing encryption keys in the DNS. Now that it’s possible to encrypt DNS communication, the keys can be fetched safely. From there, the DNS keys are used to protect the TLS handshake, which in turn generates new session keys to protect the entire connection.

After this improvement, the only piece of information that travels unencrypted is the website IP address. The solution for this is essentially to put thousands and millions of websites on the very same IP addresses. That way, those monitoring the traffic will have no way of knowing exactly what websites are being visited.

In terms of support, Chrome and Firefox are getting ready. The DefO project is updating OpenSSL. Cloudflare, which previously also supported ESNI, announced support for ECH recently but has since postponed it without explanation for later this year. We’re almost there.

Short news

Here are some things that caught our attention since the previous newsletter:

• The European Commission continued to push for automated mass-scanning of everyone’s conversations. Finland said it would vote against. Opposition needs at least 35 percent of votes to defend privacy. Bert Hubert (of PowerDNS fame) testified at the Dutch parliamentary hearing. In the end, it seems that there was enough opposition that the vote scheduled for October 19 has been canceled.
• Administrators of jabber.ru (and xmpp.ru) have detected an active network attack and TLS interception against their Hetzner and Linode servers. Is it possible lawful interception? Hugo Landau wrote a detailed blog post outlining the possible mitigation measures for this type of attack.
• Signal’s new post-quantum protocol, PQXDH, has been formally verified and improved as a result.
• Chrome announced changes to how it monitors availability of CT logs, increasing the number of endpoints monitored for better coverage. Some logs don’t reach the required 99 percent today.
• Cloudflare’s support for post-quantum cryptography reached general availability.
• Shor’s algorithm has been improved and made faster.
• Trent Novelly wrote about exploiting Chrome via Zenbleed.
• Synology NAS fixed a flaw with insecure password generation. The root cause was insecure random number generation.
• Bruce Morton wrote about certificate linting and the available tools.
• Mozilla released version 2.9 of its Root Security Policy. Among the changes are limits on the lifetimes of root key material and support for S/MIME certificates.
• Job Snijders wants to constrain RPKI trust anchors.
• Amazon provided information about its RPKI deployment, which is the largest in the world and manages tens of millions of IP addresses.
• Steve Weiss investigated the rumors behind the origin of the infamous NIST ECDSA curve parameters. He talked about it on the Security Cryptography Whatever podcast. Filippo Valsorda announced a bounty for cracking the parameters to uncover the starting seeds.
• Related, if you’d like to understand why these parameters are important and why we don’t want to use custom parameters anymore, read this article from Filippo.
• In 2024, Microsoft will start supporting (as a preview) inbound SMTP DANE in Exchange Online.
• D. J. Bernstein is not happy with NIST and its work on Kyber-512. There’s a follow-up discussion on the Post-Quantum Cryptography mailing list, plus another blog post from D.J.
• Do you know about AgileBits’s 1Password Security Design document? (Via Ryan Hurst.)
• Google continues with its Moving Forward, Together initiative. In version 1.5, Chrome’s Root Program will require CAs to support automated issuance via ACME.
• With RFC 9495, CAA has been extended to control issuance of S/MIME certificates.
• The European Telecommunications Standards Institute (ETSI) is considering making future standards public. This is in response to recent discoveries about intentional weaknesses in the proprietary TETRA radio protocols.
• The Bleichenbacher timing side-channel attack strikes TLS again. The Marvin Attack, an associated paper, and tools from Hubert Kario again highlight that we don’t know how to securely implement RSA PKCS #1 v1.5. Hubert is working on a new RFC called Implementation Guidance for the PKCS #1 RSA Cryptography Specification.
• AWS-LC, a general-purpose cryptographic library maintained by the AWS Cryptography team, is now FIPS 140-3 certified.
• The pkilint toolbox comes with a REST service packaged as a Docker image.
• Maxim Ivanitskiy wrote a blog post describing how to configure Nginx to support certificate rotation without restart.
• Sean Mullan wrote about the security enhancements in JDK 21.
• InternetNZ released a report investigating the .nz DNSSEC failure in May 2023.
• Two recent presentations discuss AES: Practical Challenges with AES-GCM and Proposals for Standardization of Encryption Schemes. (Via Frank Denis.)