31 Oct 2023
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.
This subscription is just for the newsletter; we won't send you anything else.
Here are some things that caught our attention since the previous newsletter:
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.