Tres formas en las que TLS 1.3 protege los nombres de origen

The purpose of Transport Layer Security (TLS) — and by extension, HTTPS — is to create a channel for two parties to have a private conversation using otherwise public infrastructure, such as the internet. Traditionally, the notion of confidentiality has been limited to the contents of the conversation without extending much protection to the identities of the parties, like, say, the origin name of a website. Even though most of the discussion of TLS 1.3 enhancements focuses on its performance improvements and stronger cipher suites definitions, we’re now moving into a less understood era where information about the identity of each party is better protected, too. 

Here are three common scenarios in which HTTPS may soon be able to provide better protection for origin name confidentiality than before.

Online Certificate Status Protocol (OCSP)

To guarantee that a website is indeed controlled by the party claiming to own it, OCSP checks may be done by HTTP clients to determine if a certificate has been revoked before its expiration. Let’s say, for example, a developer accidentally uploads a certificate’s private key into a public source control system as part of their continuous integration and test pipeline. When a key is exposed like that, its corresponding certificate needs to be revoked and reissued in order to prevent site hijacking.

Historically, the client sends an unencrypted fingerprint of the certificate to the certification authority for verification. In doing this, two new parties have the potential to learn which website the user is visiting: the Certification Authority itself and anyone who can see the user’s packets.

With TLS 1.3, the OCSP check is now typically encrypted using OCSP stapling. This is a clever little upgrade in which a signed attestation of the certificate’s authenticity — a seal of approval of sorts — is included directly within the encrypted 1.3 handshake. And while this leaves the Certification Authority out of the runtime entirely (which was also possible in earlier versions of TLS), it also prevents any potential onlookers from viewing the user’s packets, which is only made possible by TLS 1.3’s handshake encryption.

Server Name Indication (SNI)

A server may host many websites with a sizable set of different certificates. During the TLS handshake, the client uses a TLS feature known as SNI to let the server know which origin it needs the certificate for and, in doing so, reveals the website identity in plain text. Similar to the OCSP check, this leaves the origin identity vulnerable, in that anyone who can gain access to the packets can find out which websites are in use. This problem is a bit trickier to solve. Because the leak occurs in the client hello — the very first step of the handshake — it cannot be encrypted as no cryptographic material has been exchanged yet.

A work-in-progress prototype for this lies in separating the keying material used to encrypt the TLS channel from the new keying material used to encrypt the SNI information. By using persistent keying material specific to a CDN or the hosting infrastructure, the SNI can be encrypted separately from the rest of the connection and securely exchanged during the earliest part of the handshake. This solution, paired with the OCSP stapling solution, accounts for both major plain text packet header blind spots.

Name resolution via Domain Name System (DNS)

Before an HTTPS connection can even start, a DNS transaction is performed to learn the IP address for the website. During the DNS request, the name of that website is shared with the name server, typically provided by whatever network the client is attached to, and anyone who is able to view that communication — both of whom are outside of the two-party context of HTTPS. This is a difficult problem to solve. But the approach that has gained the most traction thus far is DNS over HTTPS (DoH): a protocol that shares the site identity with only name resolution services that the client is pre-configured to trust with that information. This solution is still not strictly two-party, but it does limit information sharing to only those entities specifically allowed as participants in the secured conversation.

With DoH, the DNS resolution itself is viewed as a service that is connected to via HTTPS. This simply shifts the information leak from the website origin name to the DNS server name. This is an improvement as, generally, the DNS server name is not a personalized, confidential piece of information that requires protection.

DoH certainly can work with TLS 1.2 environments, too. However, because TLS 1.2 also routinely leaks the service identity information that DoH protects, it is only in conjunction with the improved properties of TLS 1.3 that DoH brings a meaningful improvement.

A deeper dive into TLS 1.3

Back in November at our customer conference, Altitude NYC, I gave a talk on how TLS 1.3 is making HTTPS faster, more robust, and more responsive than ever before. Watch below for an all-encompassing look into how HTTPS continues to expand the definition of what a secure network really means.