Link Search Menu Expand Document


It is fine to use public Wi-Fi, even without a VPN. Enjoy travelling and avoid high roaming costs!

Nothing is 100% safe, but public Wi-Fi is such a small risk that it does not warrant the attention it still gets.

If you trust the network layer on any network, public Wi-Fi makes no difference. It is wrong to put trust in the network layer. You should rely at the security on top of the network layer, such as TLS.

Using public Wi-Fi was pretty dangerous when software like the Firefox plugin Firesheep were around in 2010, which could hijack a Facebook account with the click of a button. These times are over. When times change, the wisdom from that past era tends to stay around for a longer while.

Some improvements that occurred over the last 10+ years:

  • Almost the entire web moved to HTTPS. Exceptions are a rare sight these days. Additional, HSTS (with preloading) is quite widely deployed (especially at big cloud services), which makes plain text downgrade attacks hard to deploy. Due to the PCI-DSS, any retailer doing credit card transaction processing is forced to use TLS (There are certainly huge risks involved with credit cards, but those have nothing to do with public Wi-Fi). App Transport Security on iOS platforms enforces HTTPS from apps (see here).
  • Browsers are auto-updating, which is a very effective method of protecting against known vulnerabilities.
  • Devices are better hardened and it is less common to have any daemons running that could pose a risk. Windows Vista (released in 2007) already made a pop-up window that disabled file sharing on public networks. In the early days of Android, its debugging feature was unauthenticated, but this is also no longer the case.

There seems to be notion that public Wi-Fi is insecure and LTE is somehow secure. They might have some more regulations as they are generally run by big corporations, but systems like the Diameter protocol are far from secure, as demonstrated in this paper.

This is not problematic if you are not putting any trust for confidentiality and integrity into the network layer.

Fixing this by using a VPN is not a particular good idea, as written in this essay by joepie91. It mentions “known hostile networks”, but surely not all public Wi-Fi networks are known to be hostile. Usually they are providing an extra service to a customer of an enterprise, injecting malware might go against their business interest.

There is maybe one big risk: Wi-Fi access point can redirect you to a phishing page. But you should also be cautious about that without using public Wi-Fi. To protect against (financial) fraud, your first check should be the second-level and top-level domain. Only after having checked that, you can check if there is a padlock. Only doing the latter check makes no sense, which is still commonly adviced. My personal view is that phishing requires submitting data to a webpage that it should not be submitted to. Merely visiting a phishing page is not phishing. If a MitM would occur, your browser will warn you about the invalidity of certificates. Do not ignore these warnings, you are warned for a reason!

If you are a high profile target and you are afraid of someone hacking your smartphone through a zero-day in your Wi-Fi chipset firmware or a WebKit/Blink zero-day using the sign-up page: alright, turn it off, but you should probably do that with the rest of your network as well in that case. People have been infected with Pegasus using an SMS.

There is nothing wrong with avoiding Wi-Fi if you have the luxury of unlimited cellular data. But don’t avoid it for security reasons.

What about DNS?

Classic DNS connections are indeed in plain text sent over the network. But does this matter? Users mostly use DNS to look up A records for a webhost, which uses TLS. An attacker could do something with cache poisoning, but with TLS, this is irrelevant because the (server) enpoint still needs to prove that they own the certificate. But nowadays, browsers are switching or have already switched to DNS over HTTPS, DoH for short. This can also help with the usage of encrypted SNI, but that only matters for website that are deployed using a CDN, because the IP address is enough metadata to identify what website is being connected to.

Own infrastructure

Running your own public access point can however be tricky in a legal sense. It differs between jurisdictions, but you might be liable for the traffic that originates from your IP adress(es), which could cause problems with your local law enforcement agency. Use a strong WPA passphrase on your home Wi-Fi and use the guest feature with temporary accounts if that is available. Try to avoid using the router provided by your ISP, who generally have terrible security. Use a supported and updated build of OpenWrt.

If you are running a website: please deploy HTTPS with HSTS (be careful with this, especially preloading), this protects users on untrusted networks, including public Wi-Fi.

Public USB

Slightly related issue: public USB. Some public transportation companies do convienently provide USB charging in vehicles. Some security people have warned against this, because it would make people vulnerable to data theft for a variety of reasons. These include the automounting of mass storage, enablement of the debugging interface or bugs in the USB stack of the kernel. This is true to some degree (unauthenticated debugging and automounting are only happening on currently unsupported Android versions), but similar to attacks on public Wi-Fi very unlikely. Don’t worry and charge your phone. Other, more likely to happen, bad stuff could get much more worse really quickly if you walk around with an empty phone.


Written and published by Eloy Degen on a public Wi-Fi network. Released under the CC0 license in 2022. See something crucial that is missing? PRs welcome at the GitLab repo.

Comment on or Hacker News.