Cybersecurity expert Troy Hunt explains the value of a VPN

This guest post by cybersecurity expert Troy Hunt originally appeared on his blog under the title Padlocks, Phishing and Privacy; The Value Proposition of a VPN. It has been republished here with his permission.

Last month I announced I've partnered with NordVPN as a strategic adviser and as part of that effort, I wanted to be a lot clearer in my own narrative around the value proposition of VPNs, especially as the web implements more encryption across more connections. As I started delving back through my own writing over the years, the picture became much clearer and it really crystallised just this week after I inadvertently landed on a nasty phishing site. I also started giving more thought to privacy and how it's constantly eroded in little bites, a thought process that highlighted just how far we still have to go as an industry, and where the value proposition of a VPN was strongest.

In the end I broke it down into 3 Ps: padlocks, phishing and privacy. Here's the value proposition of a VPN in the modern era:

1. HTTPS Still has a Long Way to Go

This is such a mess it's difficult to even know where to begin, so let me just start with the easy bits then progressively unveil just what a train wreck the current state of encrypted web traffic is. Here's one of our “Big 4” Aussie banks and as you can clearly see by virtue of the padlock, it's served over an HTTPS connection:

Goodo! I know that what's on the page hasn't been modified in transit as it was loaded over the internet nor could anyone intercepting my traffic read it. The last bit is particularly important as I logon and would firstly, like my password not to be eavesdropped on and secondly, would also like to keep my financial information on the website secure. The great thing about the padlock in the browser is that it's assigned automatically by the browser itself; ANZ can't just say “let's whack a padlock up in the omnibar”, they only get it if the page (and everything on it) is served securely. If I choose, I can click that padlock and inspect the certificate just to give me that extra peace of mind. Now let's try the mobile app:

What's the encryption story there? No idea! What I do know is that years ago I reported a bug to ANZ about their mobile app having turned off certificate validation so even though it made an HTTPS connection, it would trust any certificate returned to the app, including one injected by an attacker. Ouch!

I also know that when ANZ updated their app a couple of years ago, they pushed it out by asking people to click on an insecure link that looked just like a phishing attack:

Whoa – @ANZ_AU – this is *really* bad form sending an email asking people to download software by clicking an insecure link to a URL shorter then redirecting to an Adobe address. You’re a bank, this is precisely the sort of phishing pattern you should tell people not to fall for! pic.twitter.com/5RtG5iDrnM

— Troy Hunt (@troyhunt) April 26, 2018

And just to go down the rabbit hole even further, as commendable as the first ANZ screen grab of the HTTPS address in the browser is, you can only get there by first making an insecure request which is what the browser defaults to when you type in “anz.com.au”:

If you want to get technical about it, yes, there's HSTS involved but it's not preloaded so the first request will always be insecure. But that shouldn't be that surprising given that only 2.3% of the world's top 1 million websites are forcing the first request to be secure:

Today there were only 107,949 sites (11%) in the Top 1 Million sites using HSTS and of those only 22,912 (2.3%) indicated preload. We still have a way to go!

— Scott Helme (@Scott_Helme) September 14, 2020

This isn't meant to be an ANZ-bashing session because let's face it, plenty of banks have had plenty of problems getting their encryption right in the past, but it shows you just how many place there are for it to go wrong. I was reminded of just what a mess the landscape is just the other day after someone pointed me at a new financial app:

WTF?! pic.twitter.com/dgkD9Q4BRh

— Troy Hunt (@troyhunt) September 6, 2020

In the ensuing discussions I had about how much we can trust the transport layer, someone pointed out that it was only a few months ago that TikTok was found to be loading videos insecurely allowing the contents of them to be manipulated whilst loading. It's kinda unfathomable to think that this sort of thing is still happening, I was dismayed enough 5 years ago when reporting vulnerabilities likes this, yet here we still are.

Then there's the long, long tail of websites that still to this day, simply don't want to protect their visitors' traffic. For example, one of Australia's most popular websites is the bureau of meteorology, still served insecurely:

And just in case you thought you'd fix this by using a browser extension such as HTTPS Everywhere, no, you can't:

This is a baffling approach given they were actually able to respond to a request over HTTPS (so they have a valid cert), but then consciously chose to redirect the traffic to a non-secure address. And before we go down the “yeah but it's a static site so nothing can go wrong” path, all static sites should serve traffic over an encrypted connection for many, many good reasons.

2. A Secure Connection to Satan is Still a Connection to Satan

This tweet by my friend Scott Hanselman has well and truly stood the test of time:

HTTPS & SSL doesn't mean “trust this.” It means “this is private.” You may be having a private conversation with Satan.

— Scott Hanselman (@shanselman) April 4, 2012

I was reminded of this only a few days ago when I came across yet another Windows virus scam, the kind that's been doing the rounds for a decade now but refuses to die. It all started with a Google alert I have set up for the term “have i been pwned”:

Initially, I was a little bit excited; does Netflix now have a way of checking your address directly against HIBP? Maybe they're plugging into the API directly from the account page there? Cool! However, moments later:

Amazing to see these scams still running after all these years. This one is complete with scary audio, here's the MP3 embedded in the page: https://t.co/BiSS8uDmsa pic.twitter.com/5EIO8YZGVX

— Troy Hunt (@troyhunt) September 14, 2020

Imagine some poor unsuspecting person seeing the warning on the screen then falling for the scam. These are massively prevalent and, per the screen grab, served over an encrypted HTTPS connection. But as Scott said earlier on, having privacy on your traffic doesn't mean you're communicating with someone you actually want to.

To test a theory, I fired up NordVPN which connected me to an exit node just up the road from me (that IP address is in Brisbane).

I've also got CyberSec enabled to kill nasty stuff off which I think it's fair to say, the scamming site above fits the bill:

Hitting the same URL sent to me in the original Google alert led to quite a different result this time:

This is precisely how it went down just this week with me receiving that Google alert, clicking the link and copping the full brunt of the scam. Clearly, I know better than to fall for it, but it did make me stop and wonder how many people do get taken for a ride by these scams.

And just in case you're wondering, the host name in the image where DNS didn't resolve is different to the final scam site as a lot of these phishes bounce you around across multiple domains. Doing a quick check now, with NordVPN off, my Pi-hole still resolved the domain:

But turning on NordVPN with CyberSec enabled, the domain was black-holed back to my local IP:

Now to be clear, I still love the Pi-hole (but let's face it, most people aren't going to be installing a Pi in their homes) and you're always going to have DNS block-lists at various states of readiness regarding new malicious domains, but I love CyberSec for the same reason in that by blocking content at the DNS level you can extend the reach well beyond an ad blocker alone. Every browser and every app on the device gets the benefit of known nasty content being binned as it's done at the OS level where DNS is defined and not on a per-client basis.

3. Security != Privacy

This is one of the most obvious value propositions of a VPN, but it deserves being examined in more detail anyway. Let's talk about privacy and I'll break it down into multiple layers beginning with this excellent drawing from Wassim Chegham:

As soon as we hit the DNS box, privacy starts to go down the toilet as your browser (or other internet connected client) makes a plain text, unencrypted query to a DNS server which is usually your ISP's. Because it's a plain text query, the site your client it querying is immediately observable by anyone sitting on the connection. So what about DNS over HTTPS, or DoH? It solves the interception problem but of course the query still needs to be sent to a DNS server somewhere and at that point, the name being queried and the origin of the query (your IP address) is still visible. From a privacy perspective, this isn't necessarily doing a lot for you.

Side note: we saw a great illustration of how much value ISPs put in being able to intercept DNS queries after the industry body for ISPs in the UK named Mozilla an “Internet Villain” for their push towards DoH. In classic anti-encryption style, the moral neutrality of crypto has led to complaints about increased privacy being used to, well, do things more privately whether they be good things or bad things.

With the DNS dance done, what's the impact on privacy then? Well, per the earlier ANZ example the initial request from the browser is still almost always sent insecurely over HTTP so everyone along the way not only sees where the traffic is going, but can also read and modify the contents of it so again, from a privacy perspective, not good. Per Scott's earlier tweet, only 2.3% of the top million websites in the world are resilient to this courtesy of preloading HSTS. But let's imagine the client has already begun communicating over HTTPS before someone starts poking around in their traffic, what then? That brings us to the next problem:

SNI is Server Name Indication and it was born of a need to host multiple sites and certificates on a single IP address. It means that whilst the contents of your traffic is encrypted, the destination it's being sent to, is not.

As Cloudflare's CEO wrote in the link above: “SNI leaks every site you go to online to your ISP and anyone else listening on the line”. Which led him to talk about ESNI or “Encrypted” SNI. Which is great except… It's only supported in Firefox (Chrome support is going nowhere in a hurry). And it's not on by default. And it requires TLS 1.3. And secure DNS. If you want to check whether it works in your own browser, try Cloudflare's ESNI checker (hint: it almost certainly doesn't work). In time, we may see ESNI get traction, but that time is going to be measured in years, not months, at least for it to gain enough market share for you to genuinely browse the internet in private. Except even then, there's a problem:

Encrypted connections are great, but whilst you're connecting to services from your own IP address, can we really call the connection “private”? If it's my IP address, what can the site I'm visiting determine about me? Here's what NordVPN's “What is my IP address” service told me, right down to my suburb:

Not only may I not want to share this information with the site I visit, I might not want them knowing I'm the same person coming back on subsequent visits (and no, browsers' incognito and private modes don't fix this). I may also not want them joining the dots on who I am by matching my IP address to other public records; HIBP presently indexes 215 data breaches that exposed IP addresses alongside an extensive array of other personal information. Now, maybe your IP address is dynamic, maybe you browsed a service from 4G and it was your wired connection you used last time, maybe it wasn't the same on multiple different exposures. Maybe…

And now, just to make it even worse, consider all the other locations content gets pulled in from just to load your average web page. Take cnn.com as an example:

There are 354 requests required to load the page including requests directly to CNN and their various subdomains, to Adnxs (a tracker), DoubleClick (a tracker) and if you scroll further down the report I've linked to above, amazon-adsystem.com (the hint is in the URL), outbrain.com (guess what – a tracker!) and by then I kinda figured I'd made my point and stopped scrolling. The privacy implications don't stop with the site you're visiting, they cascade all the way down the stack of requests that follow that initial one.

As the old saying goes, privacy isn't necessarily about having something to hide, it's also about not having something you want to share; if you're depressed and going to beyondblue.org.au then you may not wish to share that with other people. If you're having trouble with alcohol and visit aa.org.au then you may not want to share that either. If you're pregnant and hopping over to pregnancybirthbaby.org.au then, again, you may expect to keep that information private (let us not forget the story of how Target managed to “data-mine its way into [a teenage girl's] womb”). Just looking up those URLs I was imagining what sort of conclusions would be drawn about me if someone had access to my connection! (No, I'm not a depressed alcoholic teenager who's expecting…)

But privacy goes well beyond just the obvious issues too, for example folks in the US dealing with the death of net neutrality. When your ISP can see your traffic, they can shape your traffic and remember, HTTPS doesn't fix that problem, at least not today. It extends to censorship too and we start to get into a more contentious area here as that spans everything from the local cafe wifi using deny-lists to government-mandated blocks on content (the latter being particularly contentious regarding certain types of content in certain parts of the world). The point is that the privacy rights assured by a VPN are about a lot more than just protecting your source IP from being exposed to the website you're visiting; it goes well beyond that.

Summary

To be clear, using a VPN doesn't magically solve all these issues, it mitigates them. For example, if a site lacks sufficient HTTPS then there's still the network segment between the VPN exit node and the site in question to contend with. It's arguably the least risky segment of the network, but it's still there. The effectiveness of black-holing DNS queries to known bad domains depends on the domain first being known to be bad. CyberSec is still going to do a much better job of that than your ISP, but it won't be perfect. And privacy wise, a VPN doesn't remove DNS or the ability to inspect SNI traffic, it simply removes that ability from your ISP and grants it to NordVPN instead. But then again, I've always said I'd much rather trust a reputable VPN to keep my traffic secure, private and not logged, especially one that's been independently audited to that effect.

The point of all this is that when we look at the value proposition of a VPN, it's about much more than just protecting a segment of the network that may already have HTTPS anyway. We rarely see TLS implemented to its full potential, phishing remains a massive problem and we have far too little privacy when browsing the web.