Security

Apple, Cloudflare, Fastly, and Mozilla Devise Solution To Encrypting SNI

News has just emerged that Apple, Cloudflare, Fastly, and Mozilla have been collaborating on enhancing the encryption of the Server Name Identification mechanism of HTTPS at the IETF 102 Hackathon as indicated by a tweet from Cloudflare’s Nick Sullivan. The tweet congratulated the mix team from the four tech giants by saying “Awesome work” and sharing there under links to the working servers at  esni.examp1e.net and cloudflare-esni.com.

The IETF Hackathon is a platform that invites young developers and tech enthusiasts to join heads in drafting solutions for tech related issues faced by the common user today. The events are free to join, open to all, and they encourage teamwork as opposed to competition. This year’s IETF Hackathon was held in Montreal on the 14th and 15th of July. The most prominent achievement to come out of it, it seems, is the encryption of Transport Layer Security (TLS) Server Name Indication (SNI), a problem that has plagued developers for the last decade, one that members of Apple, Cloudflare, Fastly, and Mozilla have now proposed a solution to.

IETF Hackathon Event. IETF

There has been a clear global shift from Hyper Text Transfer Protocol (HTTP) to Transport Layer Security Server Name Indication Hyper Text Transfer Protocol Secure (TLS SNI HTTPS) in the last decade and a half. The problem that rose out of optimizing the TLS SNI HTTPS system was the hacker’s ability to use SNI against its purpose to match data transfer for decryption later.

Before the development of SNI, it was difficult to establish secure connections to multiple virtual servers using the same first client handshake. When one IP address interacted with one server, the two exchanged “hellos,” the server sent its certificates, the computer sent its client key, the two exchanged “ChangeCipherSpec” commands and then the interaction was finished as a connection was established. This may sound easy the way it’s just been said but the process involved multiple exchanges and responses which easily managed to get quite problematic as the number of servers being communicated with increased. If all the sites used the same certificates, then this wasn’t much of a problem, but unfortunately that was rarely the case. When multiple sites were sending various certificates back and forth, it was difficult for the server to determine which certificate the computer was looking for and in the complex web of exchanges, it became difficult to identify who sent what and when, thereby terminating the entire activity with a warning message altogether.

TLS SNI was then introduced in the June of 2003 through an IETF summit and the purpose it served, in a sense, was to create name tags for the computers and services involved in the exchange web. This made the server-client hello exchange process much more straight forward as the server was made able to provide the exact certificates needed and the two were made able to have their own conversation exchange without getting confused about who said what. It’s a little like having contact names for chats and not getting confused as to where the messages are coming from, and also being able to reply to each query appropriately, providing the right documents to whichever computer needs it. This SNI definition is exactly what prompted the greatest problem with this method of optimizing the exchange process.

The struggle many firms faced in switching to HTTPS was the adaptation of many certificates to the SNI format with individual IP addresses to perform requests for each certificate. What TLS did for them was make it simpler to generate certificates to respond to such requests and what SNI did even further was remove the need for individualized dedicated certificate IP addresses by throwing in a whole identification system across the whole network of internet. What came with the upgrade of the century was the fact that it allowed hackers to use the established “contact names” to monitor and shadow data transfer and extract the information they need to decrypt at a later stage.

Although TLS allowed for data to be sent back and forth in an encrypted channel, with SNI ensuring that it reaches the correct destination, the latter also provided means for hackers to monitor online activity and match it to its source by following DNS requests, IP addresses, and data streams. Although stricter SNI coding policies have been implemented by passing DNS information through the TLS channel as well, a small window remains for hackers to be able to use this as an identification means to follow the piece of information they would like to extract and isolate it for decryption. Complex servers that deal with greater traffic of TLS encrypted data use plain text SNI to send the communication around in their servers and this is what makes it easier for hackers to identify the channels and streams of information that they want to follow. Once a hacker is able to extract the SNI information of the data of interest, s/he is able to set up a faux replay of the command in a separate TLS connection with the server, sending in the SNI information stolen and retrieving the information that was associated with it. There have been several attempts to resolve this SNI issue in the past but most have gone against the simplicity principle that SNI operates on to make it a convenient identification method for servers.

Back to the summit that first worked to establish this method, participants from four tech giants have returned to the conference in Montreal to develop an encryption for the TLS SNI because despite the grander efficiency in the multi HTTPS adjoining system, security still remains a concern just as much as it did before.

To conceal the SNI in TLS, a “Hidden Service” must be kept under the show of a “Fronting Service” that the hacker may see. Without being able to directly observe the hidden service, the hacker will be misguided by the fronting disguise that it hides under in plain text without being able to identify the underlying secret service parameters used to relay the encrypted data. As the observer follows the trail of the fronting service, the data will be removed from the observed channel as it is redirected to its intended hidden service at which point the hacker will have lost its trail. Since the server will also be exposed to the fronting service, as the data makes its way there, a second parallel SNI signal will be sent to the fronting service to redirect the data towards the hidden service and in this direction changing process, the hacker will be lost in the web of the server. This mechanism of double tickets is further developed into a combined ticket under the same SNI. As one piece of data is sent into the server, the data produces a cooperating SNI re-director and the two work in conjunction to the get the TLS encrypted data to where it needs to go. Without being able to crack the randomized fronting service that covers both SNI tracks, the hacker will not be able to follow the trail of the data but the server will still be able to connect the two and decrypt the hidden service as the data’s ultimate location. This allows for servers to continue using SNI to optimize their data transfer in TLS encryption while ensuring that hackers are not able to take advantage of the SNI mechanism.

Close