A new proposal has been approved by the Internet Engineering Task Force (IETF) which , if passed as a standard, could put an end to the snooping of web browsing activity.
TLS Encrypted Client Hello (ECH) would complete the list of technologies which help to secure the web browsing activities of billions of people all over the globe.
So what’s it all about?
Whenever you visit a website, a number of requests are sent from your browser to various services to enable your device to identify where that website is, how to connect to it, and then request data from it.
In the early days of the WWW, these requests all happened in ‘plain text’, meaning that your browser would just send data across the Internet which anyone and everyone could read:
So for example, if you were surfing the web at work, your network administrators could see what websites you visited, the Internet Service Provider which facilitates your Internet connectivity could see the sites you visit, the administrators of any other networks your data passes through to reach your destination website that hosts the website can see where you are going, and that’s before we consider Intelligence agencies, Law enforcement agencies, and cyber criminals.
When Sir Tim Berners-Lee developed the protocols for the WWW, there wasn’t much thought to providing security over the data being transmitted by the HTTP protocol, and as such the protocol was developed without a mechanism for preventing eavesdropping.
As the use of the WWW grew, people started to become concerned about the data they were transmitting, and who might want to spy on it, or on those who read particular articles. To prevent this eavesdropping, encryption was introduced to the protocols to offer a level of protection over the data being transmitted.
SSL / TLS
The first mechanism introduced was a technology called SSL – Secure Sockets Layer. This protocol was developed in 1995 by the software engineers at Netscape as a way of allowing users of the protocol to ensure privacy, authentication, and data integrity.
SSL initiated an authentication handshake between client and server to ensure that the two communicating parties are actually who they say they are. The handshake also provided a mechanism through which data could be digitally signed to give a level of assurance that the data sent and received is not tampered with during transmission.
Over the next few years, a number of issues were discovered in the SSL processes which saw the protocol updated to v3.0, but there were other issues which still required fixing. So in 1999, the IETF proposed an update to SSL.
This update was being developed by the IETF and Netscape was no longer the developer so the name of the new protocol was changed to TLS to signify a change in ownership of the technology. The differences between the final version of SSL (3.0) and the first version of TLS are not drastic and many people still refer to WWW encryption as SSL/TLS encryption.
Since the introduction of TLS, there have been a few updates to the protocol.
TLS v1.0 was introduced in 1999 as the upgrade from SSL 3.0
TLS v1.1 was introduced in 2006 and added changes to protect against some attacks against the encryption algorithms the earlier verion used.
TLS v1.2 was introduced in 1008 and introduced some new encryption algorithms, a new approach to how clients and servers chose which ciphers to use, and a new approach to the hashes used in the digital certificates
TLS v1.3 was introduced in 2018 and to date is the biggest update to the protocol with the removal of cryptographically weak ciphers, the removal of a number of insecure and obsolete features, The introduction of newer, more secure cipher suites, the introduction of perfect forward secrecy with the use of ephemeral keys.
One of the biggest updates with TLS v1.3 is the introduction of encryption in the handshake itself. FOr a while, privacy and security experts had concerns that the handshake process could be intercepted and compromised, thus weakening the subsequent encrypted traffic. TLS v1.3 introduced a completely new process for the client server handshake which encrypts the handshake process after the initial ServerHello message to limit any snooping.
If you want an excellent byte-by-byte explanation of TLS 1.2, or TLS 1.3 – check out these links:
So its all good now yes?
Sort of.
The process of connecting to a server, getting an assurance its the right server, and agreeing on a secure process to send data is all sorted.
What worries privacy advocates though is that there are other messages sent from your device that still give the game away with regards to which websites you are visiting.
It’s always DNS!
Before you can connect to a server and begin the TLS handshake process, your device needs to know the IP address of the server – the process of deriving an IP address from a web address involves the use of the Domain Name System -DNS.
DNS is often described as being the telephone directory of the Internet. Although many people no longer have phone directories, so that analogy might have to be consigned to the Internet history vaults.
So a new way to describe DNS is that its like doing a Google search for a phone number. YOui know the name of the place you want to call, so you ask Google and it looks it up and returns a number.
With DNS, when you type a web address into a browser, a process happens on your device to see if the device already knows the IP address of the server hosting the web address.
On your device, a DNS resolver client checks your device browsing history (cache) to see if you’ve recently visited the site in question and as such, does the device already know the IP address. If the answer is yes, the device simply uses that IP address. However, if the answer is no, the address is not in cache, then the device must seek an answer from a DNS resolving server.
Most people never need to configure which server to use, its often automatically given to the device by the router in your network – typically the DNS resolving server is one managed by your ISP. So in this case a DNS query is sent to the ISP-managed server and a response is returned.
This is one of the issues that concerns privacy advocates – by sending your DNS query to your ISP-managed DNS server, your ISP can see what website you are looking for, and make assumptions that because you are asking for the IP address of a specific website, that’s where you want to go – and from that fact, make an assumption of what data you want to receive.
DoH!
The solution to the issue of DNS snooping was the introduction of DoH – DNS over HTTPS
DoH was introduced in 2018 after trials by both Google and the Mozilla Foundation. As the name suggests, DNS over HTTPS uses the encryption of DNS queries inside HTTPS transmissions.
To use DoH, you must configure your device to use one of the specially designed servers at a DNS provider which has enabled their server to receive and respond to DNS queries encapsulated within an HTTPS message.
Since its conception, DoH has now been adopted by all major browser manufacturers and by all major operating system manufacturers. In most cases, the use of DoH is optional and must be configured by the user in order to use the service.
With regards to DNS providers supporting DoH, many popular organisation provide both traditional DNS and DoH options.
- Quad 9 – (secure) 9.9.9.9 (insecure) 9.9.9.10
- Cloudflare – 1.1.1.1 or 1.0.0.1 – offers both connection types on either IP address
- Google – 8.8.8.8 or 8.8.4.4 – offers both connection types on either IP address
DoT
A similar solution to DoH is DoT – DNS over TLS. Both systems protect the DNS queries and responses, the only differences are in how that protection is applied, and what encryption technologies are employed.
2/3 of the way there
With TLS encrypting the content sent between client and server, and with DoH or DoT protecting the identity of the DNS queries we perform, the only bit of the puzzle which could give away what we are up to is a small matter of the SNI data which is sent.
SNI – Server Name Indication is an extension to the TLS protocol which allows for one server (with one IP address) to host multiple websites. A feature which is extremely common with cloud-delivered content.
The SNI data is included in the TLS/SSL handshake process in order to ensure that client devices are able to see the correct SSL certificate for the website they are trying to reach.
SNI prevents what’s known as a “common name mismatch error“: Which is what happens when a client device connects to the right IP address for a website, but the name on the SSL/TLS certificate doesn’t match the name of the website. Often this kind of error results in a “Your connection is not private” error message in the user’s browser.
The SNI data is not encrypted, and as such, this can be used to identify where a user intends to visit, and as before, the probable data they will interact with.
Enter ECH
The proposed new standard provides a mechanism for encrypting the ClientHello message – in which the SNI data is sent. By doing so, it will complete the process of making a users browsing session completely hidden from prying eyes.
The proposal will see the ClientHello message split into two separate messages: an inner part and an outer part. The outer part will contain the non-sensitive information such as which ciphers to use and the TLS version, etc. It will also include an “outer SNI”, and an “inner SNI”.
The outer SNI will be a common name which represents a user is trying to visit an encrypted website on a supporting platform – e.g. Cloudflare.
CloudFlare will use something like cloudflare-ech.com as the SNI which all websites will share on the Cloudflare network. Because Cloudflare controls that domain they have the appropriate certificates to be able to negotiate a TLS handshake for that server name.
The inner SNI will contain the actual server name that the user is trying to visit. This is encrypted using a public key which can only be decrypted by the Cloudflare private key.
After decrypting the “inner” SNI, the server will be able to identify which website the user actually wishes to visit and retrieve the appropriate certificate for that service and then build a session in the usual TLS manner.
