Your IP: Unknown · Your Status: Unprotected Protected
Blog In Depth

Cybersecurity expert Troy Hunt explains the value of a VPN

Oct 15, 2020 · 10 min read

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.

I want a “secure by default” internet with all the things encrypted all the time such that people can move freely between networks without ever needing to care about who manages them or what they're doing with them. I'm a massive proponent of Let's Encrypt's and Cloudflare's missions to secure the web and of browser paradigms such as HSTS and upgrade-insecure-requests via content security policies to help make it a reality. Yet I also find myself constantly using VPNs for a variety of security and privacy related reasons and it got me thinking – why? I mean what's the remaining gap?

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:

ANZ uses HTTPS

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:

Does ANZ's app use HTTPS?

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:

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”:

ANZ using HTTP

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:

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:

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:

The Australian Bureau of Meteorology using HTTP

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

The Australian BOM rejecting an HTTPS connection

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:

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”:

A Windows virus scam using HIBP's reputation

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:

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).

Troy Hunt connecting to an Astralian server

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:

Troy Hunt using CyberSec

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

CyberSec blocking a malicious site

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:

Pi-Hole resolving the domain

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

Pi-hole does not resolve the domain

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:

A drawing by 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.

A DNS infographic

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:

NordVPN's What is my IP address service.

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:

CNN's trackers

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 beenindependently 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.


Troy Hunt
Troy Hunt successVerified author

Troy Hunt is widely regarded as a leading cybersecurity and privacy expert and teacher in the tech community. In addition to being the architect behind Have I Been Pwned, he is also helping NordVPN further improve its cybersecurity practices.


Subscribe to NordVPN blog