Experts vs. WiFi privacy vs. VPNs
Recently on the socials there was a discussion whether VPNs are needed to protect your privacy while on WiFi. As an expert, I have comments. More to the point, I have evidence.
The last part about “evidence” is important because of tweets like the one shown below, where the author demands people believe him because he’s an expert. He was wrong, though. I’m a bigger expert, but more to the point, as you’ll see below, I can show the evidence.
Cybersecurity has changed a lot over the years, and a lot of expert advice may be outdated.
Because SSL/TLS is used everywhere, it’s relatively safe to use public WiFi. It’s not 100%, you may have your email program misconfigured to send plaintext, or somebody may trick you into ignoring warnings caused by a man-in-the-middle attack, but it’s safe enough that experts themselves use public WiFi.
You still still admonitions to avoid public WiFi by those giving cybersecurity advice. It’s one of the ways of measuring the trustworthiness of advice — especially by those claiming the mantle of an official government department qualified to give such advice. Such advice almost always sucks.
The things that still leak over public WiFi are DNS lookups, website names in SSL/TLS headers, and the IP addresses of websites. I’ll talk about all three in this post.
To fix plain-text DNS, you can now send DNS requests to public resolvers over SSL/TLS. Google’s 8.8.8.8 resolver, CloudFlare’s 1.1.1.1 resolver, and many others support it. You can configure your browser to use them, and/or configure Windows 11 to use them more broadly than just the web browser.
The screenshot below is how I enabled it in my browser (Brave); ask the AI how to enable it in your browser.
The above tweet mentions encrypted DNS as well as “ECH” or “Encrypted Client Hello”.
SSL/TLS famously encrypts the connection, but it starts with an unencrypted “handshake” or “hello” step. The server name (“SNI”) is sent during that process.
The latest version, TLS 1.3, supports an optional encryption of this handshake, “ECH”, that will hide details, including the server name.
But it’s not widely supported as the above tweet claims. Anybody can verify this trivially by “sniffing” their own packets and seeing the names of websites appear in those packets.
I’m at a bar using public WiFi and did just that, visiting “PornHub”. As you can see, the name “pornhub.com” is right there in the packet.
Don’t trust me because I’m an expert, trust the evidence. This guy demanded you trust him as an expert, but yet, he obviously got things wrong. He didn’t use a sniffer.
But the thing that really irritates me about the “trust me, I’m an expert” approach is his response to the screenshot debunking him.
The answer is that it doesn’t matter which DNS I’m using. If he were an expert, he’d know that. Furthermore, when confronted with evidence, the correct response is to either admit you were wrong or provide evidence of your own.
Instead, he attacked a possible flaw, to cast doubt on the screenshot. In the world of toxic twitters, this is the sort of things pundits do to satisfy their fanboys. The fanboys will believe my evidence has been debunked, when in fact, nothing of the sort happened.
In any case, I addressed the flaw:
As you can see, I’m getting DNS from 1.1.1.1 over TLSv1.3, but still ECH is not used by PornHub.
I admit, things can get more complicated. When I told the browser to use 1.1.1.1, it didn’t. Instead, it used “chrome.cloudflare-dns.com” server, which maps to 162.159.61.3. It’s fine, it’s the same service. To configure 1.1.1.1, I have to manually enter the URL:
Yes, such details are boring, but I’m trying to make it easy for anybody to replicate this rather than trust my word as an “expert”.
Besides DNS and SNI, the third place that leaks the website is the IP address. In the above screenshots, you’ll notice that PornHub is located at 66.254.114.41. This maps to reflected.net, a CDN or “Content Delivery Network” — not actually PornHub.
CDNs effectively mask IP addresses of the server. Content providers, like PornHub, give the content to CDNs, which in turn, give it to the consumer. That CDN’s address may simultaneously be hosting content from PornHub, Disney, the BBC, and the Department of Defense.
CDNs put their servers in major cities around the world. While you may think you are accessing a website thousands of miles away, most of the content comes from a data center located less than 100 miles away. One of these days I’ll do a robust study measuring the average distance an Internet packet travels; I bet it’s less than 100 miles (200km).
In any case, CDNs really handle “bulk” content, like the home page and videos. If I surfed PornHub enough, I’m sure it would eventually leak an IP address that can be tied to it. Unfortunately, I’m in the state of Georgia right now which blocks PornHub, so all I can see are a home page and some help pages.
Conclusion
David Plummer is right: you are far less exposed on a public WiFi than you were in the past. With near universal SSL/TLS support, encrypted DNS, encrypted Hellos, and content deliver networks, adversaries can’t see much.
But at the same time, SSL/TLS is only “nearly” universal, encrypted Hellos are not widely supported, and not everything goes through a CDN. Adversaries can still see enough.
The “expert” is correct knowing that such things exist, but he’s not an expert enough to simply put Wireshark on his network and see the exposure for himself.
I don’t know how much VPNs help. As far as the local WiFi is concerned, you are anonymous. MAC addresses are randomized these days so they can’t really identify you. VPN providers, however, are not so anonymous. Most have your user account information. Some allow anonymous payments with cryptocurrency, but still, if you connect to their service from home, they’ll have your home IP address. They promise to ignore such things, and some probably do. But ultimately, you are just shifting trust one the local bar to a remote company in Sweden.
My point is that I’m an expert and I don’t know what you should do. I can educate you on the choices, but I can’t make choices for you. Don’t trust anybody that claims to be an expert making choices for you, telling you what to do (or not do). Especially when the evidence shows they are wrong.
Stating repeatedly, “I am an expert” makes you sound arrogant and obnoxious. Using Wireshark to identify plaintext network traffic is basic skill level.
It pisses me off that WPA3 is not more widely used by default in public WiFi. It's significantly more secure than WPA2 and would be a major barrier that anyone with a sniffer would have to get past before trying to attack SSL. I think it's not used just out of laziness. You'd need a pretty old device not to have support.