I know there are several attack vectors on public Wifi, but these days are they mostly mitigated?
- Man-in-the-middle attacks: thwarted by certificate authority checking by the browser and/or certificate pinning in mobile apps. Browser will not let you advance if the certificate is invalid.
- Replay attacks: OAuth tokens expire and good sites will use nonces.
- Packing sniffing on open networks: thwarted by TSL over http and encrypted traffic (unless you have a root certificate installed).
- DNS lookups are somewhat plaintext, but now started to be done over https. Even then, attackers would know what you're connected to, but not what you are saying.
- Port scanning/direct attacks: Firewalls by default lock down ports and well-patched machines prevent this
- Email (SMTP) and other protocols: are all encrypted as well to prevent snooping.
Is using public Wifi actually dangerous? If so, what's the attack vector?
If you're sure you don't trust any dodgy certificates, sure you aren't vulnerable to any kind of downgrade attacks, sure you don't use any less-than-good sites, sure you're using DNS over https 100% of the time, sure you never use any unencrypted and/or unauthenticated protocols (like plain SMTP for instance), and sure you don't have any ports open then... yeah, I guess it's mitigated.
My personal preference would be to just use a VPN when on any untrusted network. At least then you only have to worry about the security of one "site," more or less. And of course your own open ports.
Your intuition is correct. The exception is that DNS will, by-default, be sent to the default router DNS servers, which might monitor/track what you do (most ISPs run DNS that do this too), and unencrypted HTTP. Unencrypted HTTP is more and more rare as time goes on.
Most of the "shame on public WiFi" comes from VPN companies, which are just trying to fearmonger into a sale. Sure, DNS over HTTPs isn't as widespread as it should be. Sure, some websites aren't encrypted, still. But that doesn't mean that routing all of your insecure traffic to a VPN provider so they can handle it instead is going to increase your security. It just moves the threat model from "your public WiFi network and people on it" to the VPN provider.
If you really want to be safe, you could run your own VPN with algo (https://github.com/trailofbits/algo) or manually setup WireGuard and route traffic e.g., back to your home ISP, instead. That's probably my best suggestion, rather than using any of the cliche VPN providers that advertise everywhere.
> Most of the "shame on public WiFi" comes from VPN companies
I would call that a half-truth. When I was a kid (in the early 2000's) it was exceptionally easy to crack public wifi networks. A lot of that had to do with misconfiguration and every company scrambling to create public wifi APs. It makes sense that these memories and experiences live on and have become slogans of companies vying for privacy.
TLS/HTTPS was also far less common in the early 2000s. It's so prevalent these days that unencrypted wifi connections really don't matter anymore. Computers are talking to remote servers over encrypted connections regardless of the presence or absence of wifi-level encryption.
A related factor was responsibility shirking: some companies tried to claim that the problem for their lack of authentication / encryption was a problem with WiFi. I gave a few talks back then pushing what's now termed zero trust and you could just see the instinctive rejection from the telecom guys who were used to thinking of security as a function of the physical environment. That got criticism at the time, of course, but it really became untenable after so many malware attacks finally got the point through that you could not possibly rely on trusting the network layer.
The early 2000's were a real good time. Default passwords on everything, plain HTTP. In high school I did a MITM on a coffee shop because their router had the default credentials and just had a great time watching everyone else's browsing. My dad blocked battle.net AND found the keylogger I put on his computer to recover the router password to unblock it (though he was impressed enough by my attempt that he didn't ground me) which resulted in my first foray into linux (shouts to BackTrack) so I could crack the neighbors WEP.
Once I figured out packet injection (before cellphones) I actually cracked some random company WEP in a parking lot when my friends and I got lost in order to look up directions.
While I didn't do this myself, I remember watching Kevin Rose do this on his internet show thebroken. He talks about getting an orinoco PCMCIA wifi adapter because of their broad support for this kind of thing. If you want a blast from the past, you can watch them here: https://archive.org/details/thebroken_xvid
Driver support for packet injection in Kali Linux is fantastic now, making it easy to spray de-auth packets with most hardware and capture your auth packets without having to wait.
I tested out Hashcat recently with my GTX 1060 (a modest card), and could burn through 170k WPA2 hashes a second. That's a long way from brute force, but doable for most wordlist attacks.
Oh man yeah, good time. The 90s were even better (I remember when nearly every SMTP server was an open relay, and every company used smtp.example.com so you could easily guess the hostname), although the world was so much less connected. The early 2000s everybody was getting computers so even though some tricks weren't easy anymore, there was an abundance of juice.
> When I was a kid (in the early 2000's) it was exceptionally easy to crack public wifi networks
But you're not a kid anymore and nowadays it's way harder to crack public wifi networks.
Fearmongering by VPN vendors is very real.
I wouldn't have a problem browsing my home banking on a public wifi network. Everything is tls-encrypted, my browser can do dns-over-https, and anything important (including the login) requires me to enter an one-time code from my non-smart token.
And by the way, on a public wifi you might be pray of the occasional wifi attacker where as if you're using a vpn from a vpn vendor you're by definition giving all your traffic to a company whose main specialty is networking, usually under the vague promise not to log your traffic.
Not sure why you're so downvoted. Everything you state is correct and the person you are responding to brought up completely irrelevant things. VPN companies really do use fear tactics to sell their products.
> it was exceptionally easy to crack public wifi networks
This may be because public wifi networks are public, which means they're open, which means there's no wifi password or encryption. Cracking a public wifi network takes all the effort of merely joining the wireless network with a mobile device.
Plus, the plaintext DNS is rarely altered, with even NXDOMAIN hijacking* being rare these days. Usually it's just collecting for ads or basic malware detection. Or content filtering depending on the provider.
*where instead of returning the proper "name not found" DNS error, the recursive server redirects to a site owned by the provider to show ads. Not to be confused with typo squatting where domain speculators register domains showing ads hoping people mistype URLs.
Another problem here is the initial HTTP request on the web, if the site isn't in the HSTS preload list. It's easy for this to happen when you click a link, and there are lots of HTTP links generated by protocol-less highlighting too (think foo.com with no prefix).
What usually happens these days is a redirect to the HTTPS site, but that first request can still be attacked.
I find that many sites implement HSTS and the redirect to HTTPS wrong. For example, they will have http://example.com redirect to https://www.example.com instead of first redirecting to https://example.com. According to the spec, the browser will not automatically upgrade to HTTPS next time, leaving that first request still open to attack.
[Kind of a plug: I made a test for this in my tool, DomainProactive (https://domainproactive.com). I would appreciate feedback on this kind of error.]
Indeed. I now have firefox configured to always try HTTPS first. A warning pops up if it doesn't work, and you have to click through it if you want to proceed. It turns out that a large number of sites not only have http://example.com redirect to https://www.example.com, as you describe, but https://example.com doesn't work at all -- resulting in this warning. Clicking through it, you end up at https://www.example.com.
Exactly. A commonly missed attack vector is just intercepting plaintext http and blocking https, so the browser thinks the site doesn't offer https and will just continue in plaintext. The same criticism applies to smtp using starttls, an attacker can suppress the starttls command and the default is to just continue in plaintext.
This is why an https only mode is important. In Firefox it can be enabled somewhere in the settings.
Luckily browsers are nowadays shifting towards making the initial request via HTTPS. Chrome, for example, has been using HTTPS when typing an address into the address bar without specifying http:// explicitly [1].
WireGuard is much much more secure than algo. Stay away from IPSEC: it's a very complex protocol and implementations have vulnerabilities as a consequence.
While there are many footguns in the ipsec, if you have set ip up, you can have better performance with ipsec than with wireguard.
Many devices include ipsec hardware acceleration, while wireguard ciphers are purely in software. With your typical Ubiquiti or Mikrotik device you can have much more performant connection encrypted with aes+sha than with chacha+poly.
> This led to serious vulnerabilities and backdoors.
This is a matter of implementation; not whether the implementation is in hw or sw. Do you have any examples, where there was a such issue for example in Cavium Octeon (used by Ubiquiti in their USG routers), Qualcomm IPQ-xxx or Marvel Armada SOCs (used by multitude of other vendors)?
> This is a feature, not a bug. It's quite difficult to trust commercial routers.
It is difficult to trust many routers; even if they are open source, their maintenance might be not exactly transparent.
> Citation needed. Modern CPUs are very cost-efficient at this.
Typical routers do not have desktop or server class modern CPU. They run on 700-1400 Mhz, and they are busy with things like firewall rules (why do you thing that Fasttrack on Mikrotiks exists?) or, when a beefier CPU is available, with BGP. You can test it for yourself and see, that with hw accelerated AES and SHA you can saturate your available bandwidth and with Wireguard you can saturate only a fraction (unless you have low enough bandwidth...).
Worth noting that the benefits of DNS over TLS/HTTPS (with encrypted SNI) are a bit limited. For cases where a very large number of domains are hosted on a single IP address (or pool of IPs) it's effective at masking your destination from network sniffing. (sites behind Amazon Cloudfront, Cloudflare's free plan, Google App Engine/Cloud Run, old school web hosts, etc.)
But there are still tons of sites with their own IPs, or pool of IPs, in which case seeing the destination IP will reveal what domain you're visiting with no need to observe DNS traffic or SNI. i.e. 199.232.125.140 is Reddit and only Reddit. If you visit https://199.232.125.140 you get an error that the cert is for *.reddit.com.
If your goal is to prevent your network operator from seeing even the domains you're accessing, encrypted DNS + encrypted SNI helps but doesn't get you all the way there. A VPN (or Tor) is the only true solution there. However I imagine this is a relatively uncommon need, at least for most people on HN.
I think most TLS today does not use encrypted SNI; the hostname to which you are connecting is still sent in the clear in the large majority of cases even when there are many sites sharing an IP.
There was a study that showed that even for the cloud hosted sites, traffic patterns to the IP address can reveal the site (so ESNI/ECH are not foolproof):
There was this vulnerability[1] that allowed attackers to hijack VPN connections and inject their own data into them. It affected all VPNs, including WireGuard.
I just learned about Algo but have been a long time user of PiVPN (from when they only supported OpenVPN!) on my Raspberry Pi, so in the case that I wanted to reinstall the server, I wonder if the change would bring something new to the table.
It's not a "yes/no" answer. If you're visiting http:// sites, if your OS doesn't use DoH/DoT, if you have unpatched vulnerabilities exploitable by same-subnet attackers, then maybe it's dangerous.
The question is, is it dangerous enough to:
- Use a VPN? Yes, if the VPN is free, trustworthy, and not blocked by the wifi.
- Not use the Wifi, and instead pay for data/roaming? Nah.
- Tell lay users that "avoiding public wifi" is one of the top things they should do to stay secure online? Hell no. User attention is expensive, and wifi is relatively safe.
"I don't use public wifi without a VPN" is the new "I never click links in email." It's something semi-technical users say to show off how much less pleasant their online experience is for no particularly good reason. ;)
I'm trying to reason why you suggest "if the VPN is free". If the VPN is free, I'm confident that I'm paying the VPN provider using my browsing data rather than money. A paid VPN service (somewhat) instills that small amount of trust that my browsing data is not stored/tracked/sold.
I meant like Algo. My point was only that the threat here is so small as to not be worth spending real money to mitigate it.
But I'm being a bit tongue in cheek--most users are not going to want to set up Algo. And you're right that otherwise, the VPN is probably as sketchy as the wifi itself.
a) I'm traveling
b) I remember to turn it on
c) I'm not blocked by the wifi (which is common)
IOW, while Algo is great, and I'm pretty paranoid, "distrusting public wifi" is sufficiently far down my personal threat model stack rank that I don't really care about it much.
> Use a VPN? Yes, if the VPN is free, trustworthy, and not blocked by the wifi.
I agree with most of your points; I'd just like to say that I'd never trust a "free VPN"... (Outside of "it's free since I host it".) I'd put most of my effort into vetting which VPN is best audited/trustworthy.
As an aside, the other big threat that sidesteps HTTPS certificate validation would be for the attacker to only serve HTTP. The browser will call this out in the URL bar at least. This can be mitigated by sites sending HSTS headers (forcing you to use HTTPS for future connections), but this isn't necessary universal. And requires having visited the site earlier on a "safe" network.
I have my own self hosted VPN, but I am a fan of Windscribe too, they offer a free VPN which I'd personally trust. I do pay for it, but wouldn't have any concerns recommending it.
HSTS is also pre-loaded, you can pre-load an entire apex domain (such as ycombinator.com) or indeed an entire TLD (.dev is pre-loaded).
And browsers are starting to offer HTTPS-by-default mode where the browser just interprets HTTP as HTTPS (in links, in bookmarks, almost everywhere) and if the HTTPS server won't accept the connection you get a full-page interstitial where you can choose to let it go for one site that doesn't have HTTPS if you're comfortable with that.
"Free Wi-Fi" also almost always means "no encryption on the PHY" meaning eavesdropping is trivial and MITM is much more likely. I never use public, open Wi-Fi without wireguarding home.
Do I trust ProtonVPN’s free tier less than I trust a random access point named (say) “NYC Free WIFI”? I would say no: I know who ProtonVPN is, and I’m only trusting them, not all their other users.
I agree a lot of free VPNs are shady as fuck, but free tiers from reputable companies are reasonable, and if anything may be more trustworthy than your home ISP.
As I said to the other reply, I was thinking “that you host yourself” (i.e. Algo) when I wrote this.
That said, I think this is a bit too absolute. ProtonVPN has a free tier, for example, and they’re seemingly a legit company (who make their money from the paid tier). I would not disrecommend ProtonVPN—it’s probably as or more trustworthy than most free public wifi.
But the same argument for public wifi applies to VPNs: you shouldn’t be that worried, because important things don’t rely on network trust anyway.
I setup wireguard, pihole and caddy (reverse proxy) on an rpi4 for this purpose... that and access to my internal network (nas, desktop, etc). Works relatively well, was a bit of a pain to get pihole binding properly via docker (compose file).
Using dyndns service on my domain so that I can refresh a subdomain to always point home.
Echoing the other comments about a free VPN, the only free VPN worth trusting is the one you run from your own home router, which a decent router can offer.
You're right that progress has been made on most of the attack vectors, but as you point out, DNS lookups are still often done in plaintext. CT and pinning help, but not every site does it yet. Not all protocols are TLS yet, and of those that are, some are vulnerable to downgrade attacks (including SMTP).
It's definitely safer than it was, but there are still enough potential pitfalls that I'd avoid it for anything important - or at least use a tunnel. Besides, 4g is usually better anyway.
It just means that traffic is encrypted at a lower layer in the network stack, so there are entire protocols that get "wrapped" in it, and they can't sniff the IPs you're talking to, etc. Of course, now your VPN provider can.
I would recommend installing tailscale on a pc or raspberry pi at home. Then you can use it as an Exit Node. It's dead simple with no port forwarding or dynamic dns required. If you don't want to run something 24/7 in your home a free tier/$5 vps would work the same.
If one did need to worry about trusting public wi-fi, one would also need to worry about trusting one's cell service provider or home / business ISP. And you can use a VPN for an additional layer of security over all this, but then you need to trust the VPN.
But I think you're largely correct. If I'm on wi-fi that I trust less than my VPN provider of choice, I use the VPN. And then I move on and live my life.
This depends on what threats you're concerned about. If you're concerned about malware but your devices are patched and you don't click through SSL warnings, you're probably going to be fine on either of them.
If you're concerned about privacy, your cell providers is _way_ more likely to be mining your data for resell unless you live in a country where that is prohibited.
I think connoisseurs of vintage wi-fi equipment such as the WRT-54g drive their networks with current stable OpenWrt 21.02.2, release as of February 2022.
Various vulnerabilities in your wifi driver. Some of these may require you only be in range; others may be exploitable only if associated with the network.
if you don't trust at all the place too much people like parks o trains, use warp is free and works (cloudlflare), if not don't use vpn they are a lot more likely to being hack that your local wifi and moste of them are a single company who lack any respect for the user, most tockeneisation use https meaning they are encrypted
I operate a few public networks and I would like to think they are reasonably secure. I have dhcp-guard, client isolation, and a palo alto with risk filtering. That said, I do not use any public WiFi. There's a 'what-if' factor, but also my personal LTE alotment is sufficient that I just don't care to jump through whatever annoying hoops a business might require to connect.
Is it possible to have a valid certificate for, say, cap?talone.com? The only thing you could rely on is your browser not automatically entering the saved passwords.
Funnily enough, I checked and the domain is available, so I guess such an attack is harder than I thought :D
But what's your path to victory? You now own a phishing domain, why are people going to visit your phishing site and get phished? How does the WiFi help?
There's quite a jump from "I used the WiFi in that new coffee shop" to "And also I let them replace all my bookmarks" and unless I missed something big it feels like you might just as well approach such gullible customers and ask for their bank login details to make buying coffee easier.
Yeah, that'd probably work better in email phishing. I was thinking, if you have a public AP with a decent number of users, you redirect all of their requests to your phishing domain, get the credentials, ???, profit.
Cyber crims are financially motivated and today there are far easier/lower risk options for hackers. Just look at the people who lose 6 figure crypto balances to automated twitter scams or fake crypto celeb live-stream stream replays.
How many of those people are getting hacked by someone playing games with their local network? It seems to be almost universally garden-variety phishing attacks and software bugs, none of which care what network you're on.
If I was going to worry about a network in this scenario, it'd be the cellular network used for SMS if you have the misfortune of having any accounts where that's the only MFA option.
I would say it greatly depends on the the wifi, starbucks wifi and your local provider wifi setup greatly differs. Nowadays, scanning the network in starbucks won't show your neighbours, unlike the local coffee shop. Starbucks and the like use some commercial grade stuff to provide wifi.
source : I go in coffee shops and scan the networks.
Client Isolation (sometimes AP Isolation for some reason) is a technique found in most network equipment, access points and home routers dealing with wi-fi. When used, clients won't be allowed to communicate, they'll be invisible to anyone but the AP, or router, they are connected to.
But being connected to a wi-fi network isn't a requirement to sniff wireless traffic. It's possible to also monitor traffic, and AFAIK an APs internal ACL won't matter much in that regard.
It can be done with cheap equipment. Multinationals simply have the budget to spend human resources on their network security, whereas that's often not even on the radar of someone who owns an independent coffee shop.
It's a lot safer than it used to be for the reasons you described but there is still a lot of software that doesn't use that mitigating technology.
There are some attacks on the browser like trying to strip the ssl in a way that the browser will not complain or trying to catch an unencrypted something or another.
But you also have other things like mitming software updates for other applications, OS misconfigurations.
I'd say overall less dangerous but still somewhat dangerous.
If you're an average joe, no need to worry. If you're a VIP or PEP then you should worry that you'll be targeted, and public WiFi is an easy middle man.
Do not use anything on public WiFi unless the security patches are current.
Android [can] have better defenses than a Windows laptop:
- Android has MAC randomization.
- The Bromite fork of Chrome has DNS-over-HTTPS options in settings (I think Chrome requires a command line option to configure DoH, but I don't use Chrome so I'm not sure). ISPs hate DoH. Be aware that non-browser apps will use regular DNS. Some public WiFi blocks DoH (I'm configured for OpenDNS), so be ready to fall back to another browser using regular DNS.
- Bromite has an option to always check for https - enable it.
- Tor Browser is a bit easier to get on Android.
- SMTP has an opportunistic TLS exchange that can be thwarted, so I wouldn't use it.
- For me, I would wipe the stock OS off the device and run Lineage de-Googled.
>Do not use anything on public WiFi unless the security patches are current.
That's good advice for going online in general but nothing about public wifi makes this particularly more dangerous.
>Android [can] have better defenses than a Windows laptop:
>- Android has MAC randomization.
Windows has that too [1]
>- The Bromite fork of Chrome has DNS-over-HTTPS options in settings (I think Chrome requires a command line option to configure DoH, but I don't use Chrome so I'm not sure). ISPs hate DoH. Be aware that non-browser apps will use regular DNS. Some public WiFi blocks DoH (I'm configured for OpenDNS), so be ready to fall back to another browser using regular DNS.
You are conflating Chromium and Chrome but all Chromium based browser have this under security settings [2]
>- Bromite has an option to always check for https - enable it.
Again this is all Chromium browsers under security settings [2]
>- Tor Browser is a bit easier to get on Android.
Huh? [3]
>- SMTP has an opportunistic TLS exchange that can be thwarted, so I wouldn't use it.
You aren't using SMTP directly from a consumer ISP connection anyways. If the ISP doesn't drop the traffic, the server you are connecting to will probably reject the message as spam.
>- For me, I would wipe the stock OS off the device and run Lineage de-Googled.
Sure that's great if you are privacy conscious but has no bearing on whether public wifi is safe. If anything, one could argue you are slightly less safe since Google tends to be very aggressive about signing and certificate pinning so you could be more more likely to notice if someone is doing an MITM.
> That's good advice for going online in general but nothing about public wifi makes this particularly more dangerous.
A busy public WiFi controlled by a hostile party is more likely to engage in port scans and other intrusive probes, so yes, this advice holds extra weight.
Similar issues apply to Tor guard nodes, which would be slightly more dangerous.
...did not know about Microsoft MAC randomization, thanks.
>You are conflating Chromium and Chrome but all Chromium based browser have this under security settings
Brave browser does not implement this URL after a cursory examination. It will be interesting to see if the OpenBSD chromium package offers it.
Tor is in Play and F-Droid. I doubt it is in the Windows store, but I could be wrong.
>You aren't using SMTP directly from a consumer ISP connection anyways. If the ISP doesn't drop the traffic, the server you are connecting to will probably reject the message as spam.
The parent post mentioned SMTP. If the recipient is local and valid, the remote MTA will likely accept for delivery.
>If anything, one could argue you are slightly less safe since Google tends to be very aggressive about signing and certificate pinning
Google has also unquestionably had a caustic and corrosive impact upon privacy in a myriad of realms. They can and do receive subpoenas constantly, and the only way out of their databases is wiping all of their closed-source components from your devices.
>A busy public WiFi controlled by a hostile party is more likely to engage in port scans and other intrusive probes, so yes, this advice holds extra weight.
I mean if you define the party as hostile then yeah but that also all applies to a non-public network controlled by a hostile party but [Citation Needed] that this is something that people are likely to encounter in the wild. If were at all common it would be pretty noticeable because you'd notice any certificate shenanigans and it wouldn't take that long for a technical person to come along and notice any port scanning. That's before considering that OS's typically have a more aggressive firewall posture on public networks to begin with not making them particularly juicy targets.
>Brave browser does not implement this URL after a cursory examination.
Brave has to be a snowflake but it's just a restyling of the same settings page: brave://settings/security
>Google has also unquestionably had a caustic and corrosive impact upon privacy in a myriad of realms. They can and do receive subpoenas constantly, and the only way out of their databases is wiping all of their closed-source components from your devices.
Security != Privacy and those are frequently completely at odds. It's hard to argue that public wifi is anything but a privacy nightmare but from a purely technical security perspective, I must just shrug at public wifi now.
Hostile guard and exit nodes are free to probe the origin and destination hosts, and this activity is unified on public WiFi. In Tor, they are separate issues on entry to and exit from the network. The issue is the same, and care should be taken. A hostile router will allow exactly this behavior, in both directions.
Your Brave URL does not work on my android device, nor is it listed in brave://about and is running v1.36.116.
OpenBSD does have a chrome://settings/security page, but makes no mention of DNS-over-HTTPS, and is currently at 93.0.4577.82 after a "pkg_add -u". I might check the Ubuntu snap later.
If you are compromised by a privacy issue, you are no less compromised than you are by a security issue. Your metadata in Google's systems is an attack surface that, for many people, would not outweigh the security benefits that their aggressive scanning awards.
Using Tor is much worse than using public wifi, because instead of handing all your unencrypted traffic over to McDonalds + whoever's within 100 feet of you, you're handing it over to someone sketchy enough to run a Tor exit node.
Public Wifi is significantly less dangerous than swimming in the ocean. There are risks, but if you are informed about the dangers, they are completely manageable.
I could count on one hand the number of real black hats actually sitting in random cafes around the world waiting to attack unsuspecting college students writing term papers. It's an unwarranted fear inspired by security people and the media. If you want to hack people, phishing and botnets are so much easier.
I don't think they were making a point about the technical feasibility of it, just the logistics/economics.
For the average Joe, these advanced cyberweapons and backdoors simply aren't going to be used against them. Instead, you're far more likely to come across a call center scam or fake email.
Is it, though? What is the worst thing that would reasonably affect an average person using public WiFi? I would suspect both the most common and the most harmful "cyberattack" that would occur in cafes and shopping centres is someone snatching your laptop and running away as fast as they can.
Look up SMB credential capture and NetBIOS poisoning. It’s a trivial attack that has substantial impact. With control of DHCP other attacks are also possible.
In the old days (WEP era), there was a coffee shop in [mumble] where a bunch of execs from several competing companies would hang out.
Everyone would be careful to protect their screens from snooping, but a lot of folks would connect to POP mail servers without concern.
Wireshark was hard to run on anything but Linux in those days, and WiFi on Linux could be hard to get stable except on certain hardware, but it could be done.
Today, I don't imagine Wireshark would show you much of interest on a WPA2 WiFi network.
<Insert boilerplate disclaimer about your threat model here>
The short answer is no, despite what the VPN sponsor of your favorite YT videos might say. This is actually a good question to ask if you want to assess how up-to-date someone's infosec knowledge is. In a few sentences, you can tell if they're just regurgitating the classic scary myths about public WiFis or have a more nuanced take* that boils down to 'no' (bonus points if they go on a tangent about how cool WiFi deauth attacks are).
>If you really want to be safe, you could run your own VPN
Then you are placing your trust in your VPS provider (unless you are running the VPN on your home network, and then you are trusting your ISP).
At the end of the day you have to trust someone right? (ignoring the can of worms that is TOR). I know my ISP is untrustworthy and salivating over my data. I am unable to easily translate the privacy policies of a VPS provider, but VPN providers are at least explicitly claiming that they don't sell your data.
You can't do better than trusting your ISP if you want to use the internet. You don't need to trust other parties on the road if you're careful, which is the goal of this discussion.
Unencrypted (password-less) WIFI traffic is trivial to sniff. Decide how much you care about the unencrypted portions of your traffic: SNI headers, HTTP, DNS, flow logs of which IPs you are connecting to, etc.
If you type a bank password without checking that it's an encrypted connection you might be in trouble. Pretty sure strict transport would stop that though.
The main reason seems to just be that some people care about the fact they can see what servers you connect to and what your MAC is, and that people don't always check whether things are encrypted, combined with the historical fact that there used to be plenty of important things that weren't encrypted. Now there's only a few.
Kind of a related question, but my current jobs requires that VPN is always even though we work in a zero trust environment (ie we are not accessing some company intranet that requires a VPN). Is there any point to this? Maybe it makes sense on a public network but if I'm at home it seems like needless hit to internet speed.
Not every internet protocol is encrypted by default. HTTP websites still exist. Your email client may be using unencrypted POP/IMAP. Heck random applications on your computer could be opening raw tcp sockets without you even knowing it expecting your connection to be secure.
Yes it still is, or at least may be depending on your threat model.
CertPinning and CT will go a long way, but do you know that all your software components (not only your webbrowser) use these effectively?
What is about credential snagging with tools like responder? Maybe your client will freely send a set of credentials down the line because of corporate shenanigans.
Depending on the protocol used it might be trivial for a MITM to prevent a secure connection altogether and transparently downgrade your connection to a less secure method (ie Filtering STARTTLS).
Just use a VPN. There are many attack vectors without even touching software exploits. On windows for example wpad will get all your traffic hijacked. On any OS there are non-browser processes that make unencrypted network connections as well. Even if you only allow https and check every single cert, the sites you visit (domain/host) are exposed via SNI on TLS which is a privacy risk.
The only thing different in this regard today vs a decade ago is that more websites are HTTPS-only and more browsers and OSes support DNS over HTTPS. However both of these are still very far from 100%.
Not every internet protocol is encrypted by default. HTTP is still widely used. Your email client may be using unencrypted POP/IMAP. Heck random applications on your computer could be opening raw tcp sockets without you even knowing it.
Using public networks without additional precautions thinking "everything is secure these days" is a recipe for disaster.
One side of public wifi that might be dangerous is malicious access points. A while ago there was an attack vector related I think to DHCP, which allowed a malicious AP to run commands in you computer.
A security researcher friend of mine used that and a Pineapple device inside a small and saw a lot of exploitable devices connect.
One thing I wonder about: I have Xfinity internet at home. I set my phone up to auto login to the wifi hotspots Xfinity runs on their routers. How does my phone know an access point with an SSID of Xfinitywifi is trusted before sending it my wifi password?
I’m not an expert on wifi, but I believe wpa2/3 is a handshake process where the server sends a challenge the client must solve with their password cryptographically. If the server challenge fails, the client doesn’t proceed with the handshake.
social engineering is the attack vector, as always.
a person presented with "THIS IS INSECURE!!!!1 TURN BACK NOW" when going to mybank.com will just press "Continue" because they can't be bothered, but also because that error is a red-enough herring (self-signed certificates, legitimately expired certificates, people using older OSs with stale CA bundles) for people to ignore.
yes, VPNs obviate this concern, but also many people don't use VPNs.
I would avoid it on domain connected devices. Active directory will by default attempt to connect to arbitrary smb servers (via netbios, dns, or http pitm). Once connected it will happily throw your password hash, rehashed as netntlmv2, dictionary attacks and now entropy brute forces are possible, after which they can be leveraged for varying types of badness.
PITM is remediated somewhat by HSTS which forms sort of a trust (google hsts mean https links to other resources cannot be tls downgraded, even if they don’t have a hsts directive themselves).
Any lack of secure cookie flag can leak cookies over unencrypted http, wherever hsts is not applied on a site itself (even if you’re on hsts, an attacker could theoretically request to a http resource via any unencrypted page loading, by injecting an img resource to the victim domain).
I doubt there’s any low scale attacks of the last two, but wouldn’t be surprised if nation states firewalls did this. The first attack vector is very real.
even with Dns Over Https or Dns Over Tls you are still leaking the name of the server you are connecting to (example.com, sub.example.com) via SNI, an extensions of TLS used by servers to decide which certificate to serve (one of the best examples is cloudflare).
Encrypted Client Hello tries to solve this by encrypting the client hello (the first packet sent by the client in the TLS handshake) (its predecessor is ESNI, it encrypted only the SNI extensions but it was vulnerable to a couple of theoretical attacks) but it doesn't really have decent support (you can enable it on firefox but it's behind an about:config flag and it requires support on the server side too).
Public wifi can be provided as a way to track your identity and tie it to your mobile device, email, or other identifiers. For example: https://adentro.com/
Even if you use a VPN, there have been attacks like this one[1] that allow attackers to hijack VPN connections and inject whatever data they want. Doesn't matter if you're using OpenVPN, Wireguard or something else, for that exploit.
There’s also the risk of more advanced attacks that exploit the WiFi chipsets themselves, which are a real problem when they muck with the driver (which usually have DMA access to the os) and trick the os into overwriting kernel memory.
That said, this is more a problem of connecting to untrusted WiFi than unencrypted WiFi.
As people correctly note that a lot of this VPN fearmongering, I think folks are also undercutting that it's also probably a lot of ISP fearmongering; who definitely had quite a bit to lose as internet adoption increased. I remember early on ISP's were trying to go with a more cable-esque model; as in you would have to pay more per device connected to the internet.
It's always been my belief that the fundamental driver of "strong wifi passwords" has been ISPs; after all, as Netflix knows, people like sharing :)
- Man-in-the-middle attacks: thwarted by certificate authority checking by the browser and/or certificate pinning in mobile apps. Browser will not let you advance if the certificate is invalid. - Replay attacks: OAuth tokens expire and good sites will use nonces. - Packing sniffing on open networks: thwarted by TSL over http and encrypted traffic (unless you have a root certificate installed). - DNS lookups are somewhat plaintext, but now started to be done over https. Even then, attackers would know what you're connected to, but not what you are saying. - Port scanning/direct attacks: Firewalls by default lock down ports and well-patched machines prevent this - Email (SMTP) and other protocols: are all encrypted as well to prevent snooping.
Is using public Wifi actually dangerous? If so, what's the attack vector?