3

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?

RockPaperLz- Mask it or Casket
  • 3,114
  • 21
  • 50
  • 2
    Dupe of [Is public wi-fi a threat nowadays?](https://security.stackexchange.com/q/174850/235964). 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 Nov 18 '21 at 02: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. – RockPaperLz- Mask it or Casket Nov 18 '21 at 02: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 Nov 18 '21 at 03:17

3 Answers3

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.

nobody
  • 11,251
  • 1
  • 41
  • 60
  • Thanks for your answer. When you wrote *"they can try to brute-force your password through SMB"*, to which password(s) are you referring? – RockPaperLz- Mask it or Casket Nov 18 '21 at 06:40
  • People can attack your machine on an enterprise WPA2 wifi too... – ThoriumBR Nov 18 '21 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 Nov 18 '21 at 15:07
  • @ThoriumBR I'd consider an enterprise wi-fi a public network. – nobody Nov 18 '21 at 15:10
  • @nobody Thanks. Does Windows use the admin password or the currently logged in user's password for SMB? Does it vary by Windows version? If you prefer, I can post a separate question... just let me know at your convenience. – RockPaperLz- Mask it or Casket Nov 19 '21 at 00:37
  • @RockPaperLz-MaskitorCasket You need to provide both the username and password to access an account's fileshare via smb. As far as I remember, you can access all accounts on your computer, except accounts that don't have any password at all (since Windows disables remote access for such accounts). Additionally, smb access is disabled when connected to networks marked as public. I'm not a pentester so I'm not familiar with the specifics, but you search around if you are interested. See for example: https://blog.skullsecurity.org/2009/bruteforcing-windows-tips-and-tricks – nobody Nov 19 '21 at 01:32
  • 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 Dec 01 '21 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 Dec 01 '21 at 17:54
  • @nobody Can you explain what you mean by: "VPNs are not the solution to any of these problems." Of course, a lot of personal VPNs are scams and introduce their own host of problems. But a trusted enterprise VPN (for example, a VPN setup by the company you work for) can address some of the problems you mention because it uses IPSec, which encrypts at the network layer. – hft Dec 01 '21 at 22:07
  • @hft VPNs don't solve the problem, they just shift it, and they only shift part of the problem at that. An enterprise VPN is completely fine for accessing your company's resources, but isn't a solution for personal browsing, because then you have to ensure you're employer/rogue IT admin isn't snooping on your traffic. – nobody Dec 01 '21 at 22:35
  • @nobody I still have to disagree with the absolute statement: "not the solution to **any** of these problems." For example, you mentioned clear-text DNS as a problem. If a VPN is used in tunnel mode then the only thing the attacker can see is the IP of the VPN... which seems to address clear-text DNS. – hft Dec 01 '21 at 23:14
  • OTOH, I'm not sure if DNS would go over the tunnel... – hft Dec 01 '21 at 23:16
  • @hft DNS usually does go through the tunnel. However, that doesn't solve the problem completely, since it's still in clear at the end of the tunnel. Anybody snooping on cleartext at the VPN endpoint can still see/tamper with your DNS requests. Yes, it raises the bar but doesn't solve the problem completely. – nobody Dec 01 '21 at 23:38
1

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks Steffen. Is the metadata just the unencrypted packet headers, or is there more to it? – RockPaperLz- Mask it or Casket Nov 18 '21 at 06: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. – Steffen Ullrich Nov 18 '21 at 06: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? – RockPaperLz- Mask it or Casket Nov 18 '21 at 06: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. – Steffen Ullrich Nov 18 '21 at 07:14
0

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

securityOrange
  • 913
  • 4
  • 12
  • 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. – RockPaperLz- Mask it or Casket Nov 18 '21 at 02: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". – securityOrange Nov 18 '21 at 03: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?". – RockPaperLz- Mask it or Casket Nov 18 '21 at 05: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). – securityOrange Nov 19 '21 at 02:28