Ask HN: Is Public WiFi Dangerous?
143 comments
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, 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.
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.
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.
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):
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an... https://news.ycombinator.com/item?id=28103770
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an... https://news.ycombinator.com/item?id=28103770
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.
> 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.
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.
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.
Nowadays things are a lot less fun. :(
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.
Nowadays things are a lot less fun. :(
Oh boy, bring me back to the WEP-cracking Backtrack days as a kid.
I remember buying a network adapter with packet injection capabilities SPECIFICALLY for this haha
I remember buying a network adapter with packet injection capabilities SPECIFICALLY for this haha
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
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.
There is still a lot of fun to be had!
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.
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.
> 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.
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.
Not to detract from your overall point, but a one-time code wouldn't protect you from mitm.
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.
Also things like Firesheep were pretty high profile back in the days
> 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.
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.
For the few years in college I was living off campus, I never paid for internet at all. Cracking WEP was that easy.
I used this to get internet in my first apartment: https://www.whatsmyip.org/lib/fios-wep-key-calculator/
Just checked my (old, not-used-anymore) Fios network name and there was the original password! Keeping the default password is never a good idea.
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.
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.]
[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.
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].
[1]: https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
[1]: https://blog.chromium.org/2021/03/a-safer-default-for-naviga...
no, it will relay your URL via Google Search :P
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.
*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.
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.
[1] https://news.ycombinator.com/item?id=21712280
[1] https://news.ycombinator.com/item?id=21712280
Just curious: Any practical difference between Algo [0] and PiVPN [1] from someone that has tested them? Both seem to support Wireguard.
[0]: https://github.com/trailofbits/algo
[1]: https://pivpn.io/
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.
[0]: https://github.com/trailofbits/algo
[1]: https://pivpn.io/
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.
"manually setup Wireguard"
or take the way easier route and use Tailscale, which is built atop Wireguard, but w/ incredibly simple setup and great UX
Or the equally simple Subspace [1] if you want to stick with self-hosting Wireguard directly.
[1] - The community fork at least. Upstream is no longer updated: https://github.com/subspacecommunity/subspace
[1] - The community fork at least. Upstream is no longer updated: https://github.com/subspacecommunity/subspace
Wireguard exit routing has resulted in pretty slow VPN-like traffic for me. Dedicated VPN seems like a better option just for secure browsing
Currently I use Outline as it’s designed to punch through networks that don’t want to allow VPNs. Is there any reason to switch to algo?
> be sent to the default router DNS servers
Unless you've manually specified them in your network/adapter settings, which means they won't be taken from the DHCP lease.
Unless you've manually specified them in your network/adapter settings, which means they won't be taken from the DHCP lease.
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.
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.
> Many devices include ipsec hardware acceleration,
This led to serious vulnerabilities and backdoors.
> while wireguard ciphers are purely in software
This is a feature, not a bug. It's quite difficult to trust commercial routers.
> you can have better performance with ipsec than with wireguard
Citation needed. Modern CPUs are very cost-efficient at this.
This led to serious vulnerabilities and backdoors.
> while wireguard ciphers are purely in software
This is a feature, not a bug. It's quite difficult to trust commercial routers.
> you can have better performance with ipsec than with wireguard
Citation needed. Modern CPUs are very cost-efficient at this.
> 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...).
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...).
And now you moved your "thread model" to a repo controlled by hundreds of random contributors around the world using exotics languages as Jinja?
> (most ISPs run DNS that do this too)
Is there a source confirming this, or is this just speculation?
Is there a source confirming this, or is this just speculation?
Depends on the country, but yes, they do sell that data. E.g. https://arstechnica.com/information-technology/2017/03/how-i...
That article seems to be about the US only. I'd be kind of surprised if it were legal in the EU, though I'm not a lawyer.
> WireGuard and route traffic e.g., back to your home
100% of what I have been doing for years.
100% of what I have been doing for years.
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. ;)
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. ;)
> 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 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.
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.
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.
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.
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.
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.
They actually wrote an article explaining how/why it's free: https://blog.windscribe.com/free-vpn-myths-debunked-70a0aa46...
Obviously do your own research.
They actually wrote an article explaining how/why it's free: https://blog.windscribe.com/free-vpn-myths-debunked-70a0aa46...
Obviously do your own research.
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.
Using dyndns service on my domain so that I can refresh a subdomain to always point home.
Yeah, a free VPN is almost guaranteed to be a honeypot, whereas free wifi has only a small chance of being a problem.
"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.
That's the point. If you don't trust open wifi then you would trust free VPN far less.
I don’t think that’s necessarily true.
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.
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.
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.
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.
Algo is interesting! First time hearing about it, thanks :).
This is what I use when:
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.
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.
[deleted]
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.
If the WiFi is free... you're the product!
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.
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.
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.
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.
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.
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.
[deleted]
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.
A security researcher friend of mine used that and a Pineapple device inside a small and saw a lot of exploitable devices connect.
By that logic just browsing the internet is dangerous because there was a zero click rce once.
If you patch your device and aren’t high profile, you’re probably going to be okay surfing the web.
If you patch your device and aren’t high profile, you’re probably going to be okay surfing the web.
<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).
* Unlike this comment.
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).
* Unlike this comment.
“Safety” depends on your threat model.
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.
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.
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 :)
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 :)
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.
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.
It's still potentially dangerous.
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.
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.
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.
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.
[1] https://news.ycombinator.com/item?id=21712280
[1] https://news.ycombinator.com/item?id=21712280
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.
That said, this is more a problem of connecting to untrusted WiFi than unencrypted WiFi.
[deleted]
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.
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.
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.
Quite correct. The Tor network is designed to be penetrated by hostile actors.
Before passing any sensitive data over it, you must understand what can be seen, and where.
https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...
Before passing any sensitive data over it, you must understand what can be seen, and where.
https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...
>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.
[1] https://support.microsoft.com/en-us/windows/how-to-use-rando...
[2] chrome://settings/security
[3] https://www.torproject.org/download/
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.
[1] https://support.microsoft.com/en-us/windows/how-to-use-rando...
[2] chrome://settings/security
[3] https://www.torproject.org/download/
> 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.
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.
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.
>[Citation Needed]
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.
https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...
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.
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.
https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-to...
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.
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).
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).
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.
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.
>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.
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.
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 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’m a pentester. I’ve considered running responder.put in coffee shops near $client.
Nation states _probably_ have 0click rces they could shoot at you if you’re important enough.
I very much doubt you know what you’re talking about.
Nation states _probably_ have 0click rces they could shoot at you if you’re important enough.
I very much doubt you know what you’re talking about.
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.
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.
I don’t think this is the case. Gp talks from a perspective of authority. I would be very cautious about talking about risk from their perspective.
>Gp talks from a perspective of authority.
That's pretty much every poster on HN, TBH.
That's pretty much every poster on HN, TBH.
Yes, but in most cases the advice isn’t potentially catastrophically bad.
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.
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.
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.
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 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.
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.
I definitely trust my cell service provider more than I trust some random coffee shop owner with a 15 year old unpatched WRT-54g
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.
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.
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 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.
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
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.
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.
source : I go in coffee shops and scan the networks.
Is it just that the fancy equipment won't route packets between clients?
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.
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.
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's much safer than it used to be imo, but that's due to internet security and not changes in the WiFi stack.
How does a VPN protect from security vulnerabilities if the router/hotspot itself is compromised or untrustworthy?
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.
Well you could just setup a VPN at home + DDNS using something like duckdns. No need to buy a VPN
freedns.afraid.org is another popular one.
[deleted]
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.
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
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.
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.
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/
No.
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.
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.
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.
The attack surface is large, so even if you've mitigated all the known vectors, there may be more you didn't know about.
I wouldn't blame you for just accepting the risk, situationally I might do the same, but it _is_ a risk.
I wouldn't blame you for just accepting the risk, situationally I might do the same, but it _is_ a risk.
I totally never use it. I don't trust it.
i've learned to be frugal with my plan.
Going to a coffeeshop to work is also not my thing. And I would not jeopardize the company data by risking it on a public network.
i've learned to be frugal with my plan.
Going to a coffeeshop to work is also not my thing. And I would not jeopardize the company data by risking it on a public network.
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.
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.
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.
Lookup Wifi Pineapple.
WiFi is dangerous in general, particularly the 2.4GHz microwave version, and we live in a sea of it.
It turns out that non-ionizing radiation can actually affect cells and DNA.
It turns out that non-ionizing radiation can actually affect cells and DNA.
Wait this is a whole different "5G causes autism" angle. Any evidence to back these claims?
I was being a bit sarcastic, but more seriously there do appear to be a number of papers linking wi-fi to oxidative stress:
https://scholar.google.com/scholar?as_ylo=2018&q=wi-fi+and+o...
https://scholar.google.com/scholar?as_ylo=2018&q=wi-fi+and+o...
Question is impossible to answer because you haven't stated a threat model.
- 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?