Open Wi-Fi Security | Hacker News Reader

Open Wi-Fi Security

threadreaderapp.com

14 pointsxaner415 comments

Captive portals suck, I agree.

However, isn't it a better trade-off to have a network password? Even something trivial like "123456" that isn't hard to spell for guests who may speak a different language?

It does add a small amount of friction, but network passwords can be embedded in a QR code (unlike captive portal passwords) so at least it should work for mobile devices.

What’s the point? An attacker would still be able to set up their malicious AP with the same encryption key and be able to tamper with traffic as if there wasn’t any encryption to begin with. In this case the encryption adds friction and degrades user experience while not improving security in any way.

Requiring the attacker to be active to view traffic, rather than passive (broadcasting it openly) is a very real security improvement.

Why can't open access wi-fi access points provide some sort of encryption? Couldn't the access point and clients use some form of public key cryptography for the local communication?

Totally, and force client isolation on open network.

Ugh, this is so horrible. Mostly because they have thr right idea but did it half-baked.

Avoiding wifi passwords is great, but you still need connection security,mitm is not hard to pull! You could be on a VPN and someone can mitm you! Client isolation is nice but evil twins are a thing.

The best practical solution is to use EAP-TLS, ideally you would have a captive portal that instructs clients to either run some whitelisted app/script or manually generate client certs (just an app is usually best imho). But if you're allergic to captive portals, you can still do EAP-TLS with only server authentication(like we do with most of HTTPS sites!).

Less practical: allow only VPN traffic. If the traffic is ipsec,openvpn,Tor,wireguard, always allow. If people don't have their own VPN,captive portal directs them to install/run a VPN app where the VPN terminates at the AP or at a VPN provider you pay for (or better yet,work with one of the more reputable procviders to have an audited cross-platform VPN app).

Back to the problem: even if everything used DNSSEC and TLS, a passive adversary can still see which sites you're going to. Now,you may have a hard time envisioning this threat model but imagine you're at a hotel trying to do a business deal, the other side could gain important negotiating advantage based on knowledge of what sites you have frequented(just one example).

Most sites that use https still redirect from http.that is, if you go to somesite.com, your browser gets a 301 redirect to https://somesite.com. so, if an attacker can inject a 301/308 to a site they control,your only defense is the user being smart enough to tell apart somesite.com from some-site.net or something.

Local attacks are very much a thing,i.e.:wpad,llmnr,arp,dhcp,etc....

So,basically, follow industry best practices! If someone loses money or worse because they trusted your enlightened security model,be prepared for a lawsuit!

Attempting to ease user burdern is nothing new,but reduction in security at any point needs to be met with an equal or greater security compensating control. You can't just say "most people are using https" when https is not the equivalent or compensating control for WPA2/3-PSK! An attacker needs one http connection to land their payload. 99% https usage means little here. Anyone can easily mount an evil twin with a pineapple these days.

> If someone loses money or worse because they trusted your enlightened security model,be prepared for a lawsuit!

The network is provided without any guarantee. In fact with a non-secured network there's not even a way to prove that they were connecting to the hotel's network and not someone pretending to be the hotel.

Furthermore, given your logic, would you sue ISPs, transit providers, hosting providers, etc if they happened to be involved in the data path from a malicious website to your computer? No. And if yes, then EAP-TLS would still do nothing in your case because there's still the rest of the internet to worry about.

If another guest was the pepetrator? Yes, you can sue. Much like how you can sue the hotel if another guest beats you up. Whether you win in court depends on your lawyers and the judge.

> If another guest was the pepetrator?

How do you prove that on an unsecured network where no clients are authenticated?

Also, if you've identified the perpetrator, why not just go after them directly?

You can find them after the fact if they still have a persistent connection to you device (logs or radio isolation). Or perhaps they admitted to the fact?

Why not go after them? Why not go after all liable parties? What if the perpetrator is not in a jurisdiction where you can sue?

Btw, lookup the APT group "darkhotel" and their activities.

Against a network-level adversary, DNSSEC does exactly nothing: it's a server-to-server protocol, and the interaction between the resolver on your desktop and the DNS server remains unprotected. And, of course, as you mention, even if you ran a recursive validating resolver on your desktop, DNSSEC still doesn't encrypt anything.

People should simply not bother with DNSSEC.

What do you recommend then? I think DNSCrypt is nice for client-to-server.

Edit: nvm, forgot DoH and DoT were a thing

It would be nice if the standard allowed host names as SSIDs so you could have certificates for them. But it doesn’t.

How would you make that work? How do you prove to the certification authority that you are the rightful owner of a certain SSID? What if a place somewhere else wants to use the same SSID? Who's supposed to decide (and based on what criteria?) who's the "rightful" owner of a particular SSID?

If the SSID is a hostname that’s easy, like it already is for secure websites.

Reply on news.ycombinator.com