(Yes, old thread, but I think it's worth explaining the normal attach vector here so people understand it a little better...)

Yes, HTTPS is pretty much completely secure. The issue is everything that happens before/around HTTPS being setup.

Most people access their banks website by pulling up their web browser and typing "mybank.com" into the address bar. When you do that, it first sends a DNS request to lookup the IP address of mybank.com. Your browser then sends a non-HTTPS request to "mybank.com", which then generally results in that site redirecting you to the HTTPS version, such as https://www.mybank.com - and that's there HTTPS/SSL kicks in.

There's two very simple attack vectors in that flow. By intercepting the DNS request, and/or the non-HTTPS request to mybank.com, you can take control of the session. Instead of redirecting the session to https://www.mybank.com, you can instead redirect it to https://www.mybank.co/, or to https://www.mybankonline.com, or some other website that the hacker controls. As the hacker controls that website, they can have registered an SSL certificate for it, so going to that website shows the lock icon, and at least to a cursory glance, appears to be completely secure.

In it's simplest form, that rogue website could just be passing traffic backwards and forwards to the real website so you won't even notice any difference - except that when you login they grab your login credentials (or any one of dozens of other malicious things they can do in this situation).

There are security features around today that will at least limit this style of attack, but not all sites use them. (Google for DNSSEC and HSTS to find the two most beneficial for the attack mentioned above). Your browser also attempts to help by doing things like showing "Bank Of America Corporation" next to the padlock on many sites (those using SSL certificates with a higher level of certification), but not all websites use those, and even for those that do it's relying on the user to notice that it's missing when they end up on a rogue website, which most people won't do.


The fundamental difference with using a VPN (based on the comment that "Both VPNs and HTTPS use TLS") is that VPN's use a different version of trust to confirm the site they are connecting to is valid. Your VPN software generally knows the exact site it's going to connect to (there's no redirect/etc as above), and frequently knows the SSL certificate that site uses in advance, so it's far, far more difficult to trick it into connecting to the wrong site.

Exactly! It comes down to who you trust more - the VPN provider, or whoever is providing the internet. If you're at home on Comcast or AT&T, then your Internet provider is likely far more trustworthy than most any VPN provider, so from a general security perspective there's no need to use a VPN.

However once you're on public open internet it's a different story - for two reasons. Firstly, there's the issue of do you trust the provider? How trustworthy is your local coffee shop, or the free wifi you happened to find at the train station?

But even if you do trust the provider, there's the second question of how you know if you're actually connected to that provider. I do generally trust Comcast, so if I see their "xfinitywifi" network I potentially trust it also - but how do I know that it's really xfinitywifi, and not someone simply pretending to be them? Same with Starbucks wifi, or your airports free wifi. If it's an open network, you generally can't trust it as you don't know who's really behind it. In that case, as long as you've picked a reputable VPN provider, you're probably safer with them than the open wifi.

As an example, here's an "experiment" I did a few years ago that showed just how easy this type of thing is to do, and how many people will fall for it - https://blog.docbert.org/spoofing-public-wifi-networks/