
Open Wi-Fi Security - xaner4
https://threadreaderapp.com/thread/1220813454824570899.html
======
diebeforei485
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.

~~~
Nextgrid
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.

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

------
brylie
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?

~~~
m-p-3
Totally, and force client isolation on open network.

------
badrabbit
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](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.

~~~
tptacek
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.

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

Edit: nvm, forgot DoH and DoT were a thing

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

~~~
Nextgrid
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?

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

