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

Virtual private networks (VPNs) have been the cornerstone of personal and corporate security for several decades now, but we still can’t get them to work properly. This has been highlighted by TunnelCrack, a combination of two widespread vulnerabilities released under a single brand name. When either weakness is exploited, attackers end up redirecting user traffic outside the protected tunnel. The researchers tested a great number of products and report that every VPN product is vulnerable on at least one device.

In the LocalNet attack, adversaries trick victims into connecting to their malicious Wi-Fi networks. Most such networks are configured to use a private address space, one of several IP address ranges reserved for this purpose, but LocalNet turns things around by deliberately using the actual public IP addresses of the services that are being attacked. Because VPN clients tend to ignore local traffic, in the ensuing confusion the traffic that is supposed to be protected actually isn’t.

The other attack, called ServerIP, is conceptually similar in the sense that it also tricks VPN clients to send traffic without encryption to an address they deem to be “safe.” Apparently, many VPN clients don’t encrypt traffic to their VPN server, expecting that they will be the only party communicating with it. But if the client refers to the VPN server by name (e.g., vpn.example.com) and the adversary is able to intercept the DNS lookup that converts that name to an IP address, then ServerIP is successful. In the attack, the adversary returns the IP address of the service they wish to attack. Any traffic sent to this IP address will bypass the secure tunnel.

Having spent some time in the past working with OpenVPN, the description of the current state of VPN clients matches my experience. Correctly configuring a VPN requires a significant amount of expertise in encryption and routing, and the fact that most documentation out there is either obsolete or wrong doesn’t help. WireGuard improved things a lot when it comes to encryption, but the problem with the routing still remains.

It is very unfortunate that even the VPN clients don’t work correctly on mobile devices, because most users aren’t experts or can’t even configure anything at the local level.

However, it’s devastating that none of these attacks are exactly new. The knowledge of these attack vectors existed (a blog post from Andrew Ayer, for example, describes the problems in some depth), but we collectively failed to preserve it and transfer it to the new generations of programmers when VPNs started to take off.

There is a silver lining, which is that none of these VPN attacks work against properly configured services that rely on encryption. A combination of TLS, valid certificates, and HTTP Strict Transport Security will do the trick.

If you think that none of this is very likely to happen in the real world, perhaps the work of the MoustachedBouncer cyberespionage group will convince you otherwise. It’s been reported that this group, active since 2014, targets foreign embassies in Belarus. Their approach to hacking is to execute active network attacks that hijack plaintext HTTP traffic to deliver malware using fake Windows updates.

There is only one conclusion: all network traffic must be authenticated and encrypted.

Short news

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

• Nessie 2023, a CT log operated by DigiCert, was found to have misbehaved. Because the log can no longer be trusted, it will not be used for certificates issued after August 25. Earlier this year, a bitflip in the Nessie 2024 log forced it into early retirement. Last year, two Yeti shards had to be retired because of a database issue.
• AMD had a bad month, suffering not one but two speculative execution vulnerabilities: Zenbleed and Inception.
• Intel had its hands full with Downfall, another speculative execution vulnerability that used encryption key extraction for its proof of concept. Intel posted an interview with Daniel Moghimi, who discovered the problem.
• Facebook continues on its path to launch default end-to-end encryption in Messenger by the end of the year.
• The Tor project added a proof-of-work (PoW) defense against denial-of-service attacks. When an onion service is under stress, it can choose to challenge clients with increasingly CPU-intensive tasks.
• DigiCert and Corey Bonnell released a new update for pkilint, adding support for the CAB Forum Ballot SC-62 requirements.
• Chrome 116 has added support for quantum-resistant TLS handshakes. The increased size of ClientHello, the initial handshake message, is causing problems with Vercel and Zscaler, and possibly others.
• Sergio Garcia forked libx509pq into libz509pq, adding support for Zstandard compression with a custom dictionary, achieving roughly 50% compression of certificates.
• Michael Stepankin wrote about mTLS implementation issues.
• Keystrokes are under attack from all sides. Researchers have figured out a way to steal data with 95% accuracy using sound alone. In other news, the most popular Chinese keyboard app was found not only to be transmitting all data to the developer, but also to be using weak encryption, enabling third parties to also collect the data.
• Nick Sullivan reported on Twitter that Encrypted Client Hello (ECH) is now enabled for 1% of Chrome users.
• Ars Technica reported on Microsoft’s Secure Time Seeding Windows feature, which sometimes uses TLS to establish the correct time—and apparently sometimes gets things wrong. Perhaps Microsoft didn’t get the memo that gmt_unix_time was deprecated?
• Chrome’s built-in public key pinning (of Google’s own properties) has been enabled on Android. We didn’t even know it didn’t work on this platform. Chrome can also now update its pin sets, CT information, and root stores dynamically.
• Global Encryption Day 2023 will be held on October 21, 2023. Fifty mini grants of $1,000 each are available, courtesy of the Internet Society Foundation.
• Cult of the Dead Cow released a new peer-to-peer network communication protocol called Veilid, intended for building privacy-focused applications.
• Microsoft is starting to disable TLS 1.0 and 1.1 in its platforms.
• OpenSSL is looking for a community manager.
• Mark Cox wrote about the financial aspects of the OpenSSL project.
• IETF published Delegated Credentials for TLS and DTLS as RFC 9345. This specification, inspired by Heartbleed, makes it possible for end entity certificates to issue special short-lived delegated credentials to use in TLS handshakes.
• The Brave browser is now enforcing Certificate Transparency. Of the major browsers, only Firefox is now missing.
• Wired ran a story exploring the possibility of the Kremlin having access to Telegram messages.
• A portable C implementation of the AEGIS family of high-performance authenticated encryption algorithms called libaegis is available on GitHub.
• Chrome continues on its path to encryption by default with further expansion of its HTTPS-First mode.
• Michael Stepankin discusses in a blog post several vulnerabilities he discovered while auditing code for mutual TLS authentication.
• Paul Bottinelli writes on NCC Group’s blog about a subtle issue the group discovered while auditing a random number generator. It turns out that Java has both signed and unsigned right shift operators, and only one of these was appropriate for that specific piece of code.
• The PKI Consortium requested feedback on its PKI Maturity Model.
• Remote Attestation TLS (RA-TLS) integrates Intel SGX remote attestation with TLS. This approach makes it possible to achieve a greater level of security, assuming trusted environments are used for all network interactions. A blog post by Bobbie Chen describes being able to verify that the server is running the exact version of the source code. RA-TLS appears to be focused on the remote attestation of server-to-server communication.
• Eric Rescorla reviews Google’s Web Environment Integrity (WEI), a system to support remote attestation of browser environments. He’s not a fan.