Free Wifi: Is It Safe?

I was down in Liverpool and London last week and stayed over in a hotel. One thing that really surprised me was there was no complicated…

Free Wifi: Is It Safe?

I was down in Liverpool and London last week and stayed over in a hotel. One thing that really surprised me was there was no complicated process of enabling the wifi connection, and where I did not have to log in with a password and my room number. In both cases in different hotels, the SSID of the password was “Free Wifi” and had no password.

So, is connecting to “Free Wifi” in a hotel safe? Well, of course, the answer is “No”. The four main risks are:

  1. Someone in the room near to me could be advertising their hot spot for me to connect to, and I could connect to that one. They then become a proxy, and where they can break the encryption tunnel created by TLS. The flaw here, is that you can’t tell a valid wifi access point from a malicious one.
  2. Someone else on the wifi network could reply back to the request for a default gateway with their computer and for traffic to flow through their computer and not the wifi access point. A standard sign of this happening is when you connect for around 90 seconds, and then it drops for another 90 seconds, and so on. This is caused by the main gateway competing with the fake gateway and sometimes winning. The flaw here is the ARP protocol
  3. DNS requests go out in a plain form. The flaw here is the DNS protocol.
  4. The IP addresses of network connections can be seen (and which can be linked back to domain names. The flaw here is the lack of a trusted proxy.

What you should always do — for corporate work — is to enable a VPN on the connection, and where all of the traffic destinited for your corporate network will be tunnelled to the VPN server. It would not matter that you connected to a malicious gateway (but, of course, they could see all the other traffic which was not tunnelled)

The problem

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.