Stopping Your Local Coffee Shop From Viewing Your Accesses: Meet Encrypted Client Hello (ECH)

--

The Internet is often flawed in its use of networking protocols in cybersecurity — and basically, we are still using the methods defined in the original RFCs. And, for TLS handshakes, that is a particular problem, and where we have struggled to preserve privacy in the connection details.

One major problem area is when the server name that someone is connecting to can be seen by an intermediatory — as the first parts of the TLS handshake are open to capture. This means that your ISP and your coffee shop Wi-Fi network can spy on your accesses (but not the detail of the content that you are looking at).

Now, a new proposed standard from the IETF defines a replacement for ESNI (Encrypted server name indication) and masks the Server Name Identification (SNI) in a TLS connection [here]:

In the end, only the user, a trusted encryption host, and the server will be able to see the host that is being connected to. There are still other areas that a coffee shop could spy on you, such as with the destination IP address, and in DNS look-ups, this, at least, a step forward in supporting privacy. If you are concerned about the privacy of your DNS, you should investigate DNS over HTTP (DoH), and for the shielding of IP addresses, a proxy can be used.

The problem with the TLS connection is that the encryption key of the session will not be defined before an encryption tunnel is created, and so all the details about the connection will be revealed. But, with ECH (Encrypted Hello), we can now perform the handshake with a proxy entity, and where it will not be possible to see the end server connection and for the server to see which client is connecting. One of the first companies to implement an integrated ECH and DoH approach is Cloudflare and who outline the process as:

https://blog.cloudflare.com/announcing-encrypted-client-hello/

Here is an outline of TLS handshaking:

ESNI

We connect to public wi-fi systems and think that we are not giving away the sites we are visiting, as we are using HTTPs connections. But think again, our DNS requests reveal the sites we are connecting to. Also, the start of the TLS connection actually reveals the site we are connecting to.

So in our sticking plaster world of security, we leak lots of information. One of these things are the servers we connect to. Cloudreach is one of the leading companies in the world which is trying to force the industry to plug the games around DNS and TLS. They would like to see the world moving to TLS 1.3 as quickly as possible.

And so Cloudflare recently announced that they have implemented ESNI (encrypted Server Name Indication (SNI) TLS extension). This aims to stop ISPs and public wi-fi providers from snooping on your Web accesses (or anyone else who listens to your network packets). The first integration is within Firefox Nightly, and you can test your browser here:

Cloudflare is also pushing to secure DNS requests while driving the move toward DNSSEC and TLS 1.3. Once ESNI is enabled, it should show the following:

Cloudflare has released Wireshark traces to show the difference. The following shows a normal TLS and where we see the server name (cloudflare.com) within the TLS packet:

If the encrypted SNI extension is now added we get:

A TLS connection should be secured and tunnel, but in the initial negotiation with the Client Hello we reveal the server name, and which can be seen by anyone listening to our network packets.

With ESNI, the server with a DNS record publishes its public key. The client then changes the SNI extension to an encrypted version. The key used is a symmetric key derived from the server’s public key (using Elliptic Curve Diffie Hellman key exchange). The associated server which owns the associated private key can also derive the same symmetric key, and can decrypt the extension. This can only work with TLS 1.3 and above. With TLS 1.2 and below, a snooper can examine the digital certificate that is sent from the server to the client, and thus determine the site to which the user is connecting to.

Conclusions

TLS 1.0, TLS 1.1 and TLS 1.2 need to be dumped asap. We need to improve DNS, too. Well done to Cloudflare in pushing the industry forward. Google has changed the world with their drive for HTTPs. We need to do the same with some of the other protocols, and properly plug the gaps we have created.

Here is an article on TLS 1.3:

https://medium.com/coinmonks/a-bluffers-guide-to-tls-1-3-330b0fd3e65e

Sometime soon, our 20th Century Internet needs to be switched off, and replaced with one which truly respects the rights of our citizens to privacy.

--

--

Prof Bill Buchanan OBE FRSE
ASecuritySite: When Bob Met Alice

Professor of Cryptography. Serial innovator. Believer in fairness, justice & freedom. Based in Edinburgh. Old World Breaker. New World Creator. Building trust.