If a non-compromised device is connected to the internet via open Wi-Fi, anyone can view the traffic.

But if all the connections to the servers use a reasonably secure cryptographic protocol (such as a recent version of TLS), is the communication secure?

If so, what is the harm of using open Wi-Fi if one only allows TLS v1.3 connections?

  • 2
    Dupe of Is public wi-fi a threat nowadays?. However, I must state that I heavily disagree with the accepted answer. For starters, it's perfectly possible to use the internet with HTTPSEverywhere or equivalent to avoid SSLStrip attacks. Secondly, the recommended solution in that answer is a VPN, which only shifts the problem, and does nothing to stop other types of threats (like attempted exploitation of the machine itself).
    – nobody
    Commented Nov 18, 2021 at 2:27
  • @nobody Thanks. Just FYI, HTTPSEverywhere was recently deprecated by the EFF. It still works, but I thought you would appreciate knowing. Also, as you mention, VPNs just shift any issues, and don't necessarily resolve them. Commented Nov 18, 2021 at 2:50
  • Thanks for reminding me about that. I should have written "HTTPS-Only mode", which most major browsers have (although it is usually disabled by default).
    – nobody
    Commented Nov 18, 2021 at 3:17

3 Answers 3


TL/DR: Using a public Wi-Fi is fine as long as you are making sure not to visit any site without TLS, and keep your device (particularly OS and browser) up to date.

Man in the Middle Attacks

An open Wi-Fi cannot compromise a properly secured TLS connection. But not every TLS connection is properly secured. The majority of the sites do not use HSTS (although thankfully most major sites do), which means they are vulnerable to SSLStrip attacks. Most normal users, and even most tech savvy ones, will not notice it. The solution is to turn on the HTTPS-Only mode in your browser.

DNS is mostly also in clear, which allows anybody sniffing your traffic to intercept responses to your DNS requests and modify them. However, they will still be unable to forge a valid TLS certificate, so your browser will throw a warning. If, however, you are paranoid and want to make sure people on the open Wi-Fi cannot even see your DNS requests, you can enable DNS over HTTPS.

Attacks against your Machine

On a open/public Wi-Fi, an attacker can also try to attack your machine directly. For example, they can try to brute-force your password through SMB, or attempt to exploit any recent OS vulnerabilities for which you may not have a patch installed. Obviously, the solution is to keep your system up-to-date. If you're tech-savvy enough, configuring your firewall to block all unwanted incoming connections will help. (On Windows, marking a network as public will tell the OS to close several of the holes in it's firewall.) Of course, if your threat model includes zero days, you might want to stay away from public Wi-Fis altogether

Note that, contrary to what some older posts on this site might imply, VPNs are not the solution to any of these problems.

  • Thanks for your answer. When you wrote "they can try to brute-force your password through SMB", to which password(s) are you referring? Commented Nov 18, 2021 at 6:40
  • People can attack your machine on an enterprise WPA2 wifi too...
    – ThoriumBR
    Commented Nov 18, 2021 at 10:46
  • @RockPaperLz-MaskitorCasket Your OS password. At least on Windows, SMB uses the OS password for authentication, which means an attacker attempt to bruteforce it, although of course it won't be be as fast as offline bruteforce.
    – nobody
    Commented Nov 18, 2021 at 15:07
  • 1
    @RockPaperLz-MaskitorCasket SMB (Server Message Block, a.k.a. Windows Networking) typically requires clients to authenticate (log in), but they can do so via any account for which SMB is enabled. By default this is all accounts that have passwords at all, although of course if the account is disabled (as the Admin account is by default on modern Windows) then they can't use that, and if SMB is either disabled (turn off the "Windows Server" service), blocked at the firewall (done by default for the "public" firewall profile), or not sharing anything, then that also limits or prevents attacks.
    – CBHacking
    Commented Dec 1, 2021 at 17:51
  • 1
    Note of course that there are other ways to attempt remote access to a Windows machine beyond SMB. There's Remote Desktop (if enabled, the client only needs to know the username and password of an allowed used), various remote administration functions via RPC (usually disabled outright or at least blocked at the firewall for public profile, requires logging in with some user usually an admin), SSH (not enabled by default but available), and of course any server software you're running (anything from a Minecraft server to a development version of an unreleased webapp).
    – CBHacking
    Commented Dec 1, 2021 at 17:54

But if all the connections to the servers use a reasonably secure cryptographic protocol (such as a recent version of TLS), is the communication secure?

This would mean HTTPS for websites, DoT or DoH for DNS, SMTPS/IMAPS for mail ... . If for all of these proper encryption is actually enforced then the connection is safe against manipulation by some man in the middle (owner of WiFi, attacker ...). But it is not safe against sniffing meta data. Such meta data are obviously the IP addresses one connects to, traffic pattern like timing and the amount of transferred data, ... But most current TLS connection contain also the name of the target server clearly visible in the handshake (SNI - server name indication).

So even if an attacker cannot manipulate the traffic it can still gain lots of information about what you are doing and can also selectively block traffic. Apart from that encryption is not the default or not enforced for many protocols (like DNS), so one currently cannot even rely on having the minimal protection of encryption.

To secure the communication it is much better to additionally use a trusted VPN with a VPN endpoint outside the reach of the kind of attackers you find relevant. This adds another layer of protection to what you already have and let the attacker only see that there is some VPN traffic to some VPN endpoint, but not the details of the connections within.

Apart from that, securing the communication does not mean that the transferred content is secured, i.e. things like malware can well be delivered by HTTPS too. It also does not make connections to possibly exposed local services more secure, i.e. they might still be attacked from outside.

  • Thanks Steffen. Is the metadata just the unencrypted packet headers, or is there more to it? Commented Nov 18, 2021 at 6:38
  • @RockPaperLz-MaskitorCasket: The transport level (IP, port) is not protected by TLS in the first place, i.e. TLS is only about application payload. Additionally TLS handshake exposes metadata like server name. These are protected against manipulation, but not against sniffing. Commented Nov 18, 2021 at 6:39
  • Right, so someone can easily know that Steffen connected from IP x at 12:00 to a server on IP x on port x that likely belongs to company XYZ, but that's about it, correct? Commented Nov 18, 2021 at 6:43
  • @RockPaperLz-MaskitorCasket: Again, IP address in transport level and domain name in TLS handshake. Also timing and payload sizes. This can give lots of interesting information to an attacker. It might or it might be not still sufficiently secure for you. Since you don't describe any specific threats you want to protect from it is impossible to tell what level of security you actually need. Commented Nov 18, 2021 at 7:14

The answer to every question of "Is X secure?" comes down to your threat model. What are you trying to defend against? That information will change your decisions dramatically. If you're worried about some nation-state actor with their eye on you, then your concerns around public WiFi will be entirely different than if you're worried about a bored loiterer with a WiFi Pineapple and low skill.

That being said: personally, I use public WiFi with HTTPS and certainly with TLS 1.3. For my concerns, I believe it is sufficient for daily use.

Remember that perfect security never exists; the thing to go for is sufficient security. (That's my own philosophy anyway.)

  • Yes, just what 99% of people would consider security. No more. No less. In other words, no reasonable chance that a malicious actor can do anything malicious or unauthorized. I somehow doubt people concerned about nation-state actors ask questions on StackExchange hoping for an accurate answer. Commented Nov 18, 2021 at 2:48
  • I agree with the conclusion there, with the exception that I believe the distinction still needs to be made because the underlying question is coming from a wrong premise. There is no "secure", only "secure enough for what I need to do". Commented Nov 18, 2021 at 3:42
  • 1
    Good point. I think better terminology is needed on my part. Is there a word for "secure enough for typical computing activities, but not so secure it needs to withstand the resources of a nation-state?". Commented Nov 18, 2021 at 5:54
  • Hm...I would probably describe that as "reasonably secure for private use" or something along those lines. It's secure enough for - well, anything I would want to do as an individual, but I don't think I'd put my enterprise on public WiFi (...for many reasons...). So I think the key is that it's basically for one person as a person, not as an entire business (or something like that). Commented Nov 19, 2021 at 2:28
  • I find this answer to be too generic. It can apply to practically every single security related question, without giving you anything useful.
    – Dr Phil
    Commented Jul 6, 2023 at 15:14

You must log in to answer this question.

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