3

It's common knowledge that one shouldn't login to personal or bank accounts on public wifi such as in a starbucks or a hotel. However, assuming that the connection is HTTPS and the passwords itself are encrypted, how is it not secure? Because if the connection is https, then even your ISP can't see exactly what the webpage is, so how can a potential hacker know even more?

4
  • 1
    Your risks are low, but nonzero. Your connections will be visible, and if you're using standard DNS, so are the hostnames. This limits your privacy. A highly sophisticated attacker may be able to get a valid enough certificate to perpetrate a man in the middle attack. Some of your traffic might not be encrypted (perhaps a Windows exploit can be run against you?).
    – Adam Katz
    Mar 29, 2022 at 20:59
  • The crypto currency KLAYswap theft from Feb 2022 has shown that even a fully secured HTTPS connection can be "broken" by attacks on BGP and the flows in the PKI system: you can just issue a new certificate by a different legitimate CA: freedom-to-tinker.com/2022/03/09/… as for most certificates you only have to prove that you control the server that servers the web site for a specific DNS entry.
    – Robert
    Mar 30, 2022 at 11:42
  • @Robert While that is an interesting and scary attack, using a private personal network is not going to protect you against this.
    – nobody
    Mar 30, 2022 at 13:34

2 Answers 2

5

Public networks make it easy to get a MitM position. TLS (the security protocol underlying HTTPS) is secure against MitM by design, but neither software nor users are perfect executors of good security practice, and public networks offer more opportunities for attacks. A selection of potential attacks:

  • Attacking the TLS protocol or implementation on your machine. Most TLS vulnerabilities (protocol or implementation) have required or at least benefited from a MitM position.
  • Attacker your machine directly, for example by attempting to exploit vulnerable or unprotected servers or maliciously manipulate response traffic to compromise vulnerable clients.
  • Attempting "SSL Stripping" attacks, where if a connection is initiated over plain HTTP (or SMTP, IMAP, etc.) and the server tries to upgrade the connection to TLS, the attacker can intercept that redirection / upgrade message, go to TLS itself on the server side (but not the client side), and spoof being the server while the client continues using a plain-text connection the attacker can read and modify. Requires the connection be initially made over an insecure protocol (i.e. not starting with HTTPS) and that the user not notice the failure to upgrade to a secure connection. Mitigated (for web content) by HSTS.
  • Attempting to trick the user into clicking through a browser warning, such as for a self-signed, third-party, or otherwise untrustworthy certificate.
  • Using a fraudulent certificate, if the attacker somehow has one, to impersonate a legitimate server without needing a large-scale DNS misdirection.

All of these attacks can in theory be carried out without the victim being on a public network, but it's easier if they are. Some of them are a risk any time you're on a public network, and whether you're managing a billion-dollar portfolio or playing Cookie Clicker doesn't matter. Most of them have various mitigations the user can take, like keeping software fully up to date and never using plain-text protocols even briefly.

There are other, non-network risks that are relevant when in a public space. An attacker might see an OTP arriving via SMS or displayed on an authenticator app, and try to use it themselves. An attacker might watch you type a password, perhaps through a camera that is recording so they can rewind and slow down the playback. An attacker might read sensitive or confidential content on your screen and gain private information. An attacker might use or steal your device if you leave it briefly unattended. These all have mitigations you can take as a user, though.


In conclusion, public networks (and public spaces) increase attack surface. There's no guaranteed way for a victim to get in, and the user can mitigate almost all of the risks (a few, but not all, of which are mitigated by just not accessing sensitive sites while in public), but it is a higher-threat environment. At the very least, one should be more vigilant.

However, in practice, I suspect the marginal increase in risk is greatly overstated. Lots of security training is so overwrought about this topic that you'd get the impression that public routers have magical decrypt-everything-and-take-over-your-device powers, which is of course false. This is probably easier than getting people to reliably behave correctly in the face of network attackers with a MitM position, but it also introduces a lot of costs, and the threats you face are not unique to public networks. Do you ever do business over a cellular network, or connect to office WiFi just on the basis of it having the expected SSID? Those are also attackable networks.

With all that said, you definitely shouldn't trust public devices for anything secure. Even leaving aside the risk that you'll walk away with sensitive data (ranging from browser history to still-valid session tokens) left on the machine, there's a considerable risk of malicious software or hardware (keyloggers, spyware, malicious CA certificates, worms that try to infect removable storage you connect, etc.) on such systems. In some parts of the world, it's nigh-impossible to find an internet cafe computer that isn't visibly compromised.

4

Leaving out all the problems of "connecting to an unsecure WiFi network1 and having your screen and keyboard in a public place2", there is at the very least the residual possibility of a successful HTTPS man-in-the-middle attack.

So you should have HTTPS, encrypted passwords, and the means and/or the knowledge to recognize when this kind of attack is being undertaken - means and knowledge that may be obvious to you, but usually are not to the larger public.

Therefore, when you need to describe the "safety" requirements, you ought to say, "if the connection is encrypted and the WiFi is protected and passwords travel only in hashed format and the user is knowledgeable". Unfortunately, most non-knowledgeable users believe they're knowledgeable enough ("of course I'd spot a hijacked certificate, come on!").

But I have seen myself people that ought to have known better, that knew there was an audit going on, choose to ignore a bad certificate warning on a site they believed secure, because I had made them think the audit's focus was on something different. A little distraction and poof they went. Okay, two thirds of those people passed the test, spotted the danger and even correctly called me out and smiled, "Nice try!" - but the fact remains, one third did not.

So, even secure WiFi and HTTPS is not by itself secure enough, and therefore, is not secure enough.

That said, if you're knowledgeable and prepared, it can be secure enough for you - but that's a completely different thing.


(1) with most default configured APs, you get an IP in a network - say 192.168.0.0/24 - where anyone can access your computer, i.e. you get 192.168.0.2, I get 192.168.0.3, I can now run a portscan against 192.168.0.2 and it will work, unless the AP has the rarely-present, rarely-activated "Client Isolation" option toggled.

(2) this actually happened in my home country in 2013, and it was quite the scandal: we have TV broadcast of parliamentary works. Some cameras are behind the deputies, and can show what they're doing - such as logging on their email from a touchscreen tablet - in 4K. It happened exactly what you might think it could happen.

1
  • 1
    @Robert That depends on the setup. Solely a "untrusted certificate authority" error can be ignored in Edge, Chrome and Firefox. If HSTS is used, then the error cannot be ignored.
    – user163495
    Mar 30, 2022 at 14:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .