Hacker News new | past | comments | ask | show | jobs | submit login

I'm most excited about "Enhanced Open."

The reason Open WiFi never had encryption is essentially because people argued that if a connection cannot be perfectly secure then it shouldn't try to be secure at all. Or the exact opposite of defense in depth.

Enhanced Open does what we should have been doing since WPA1, Opportunistic Wireless Encryption. It is imperfect, but a substantial improvement over current Open WiFI.

To quote Voltaire "Perfect is the enemy of good."




This so much. Same with https errors (so people keep using http) and client side hashing in password forms ("but an active attacker could replace the Javascript and make you submit the unhashed version of your password" so we should just let passive listeners listen?)


> Same with https errors…

That's a branding issue: we've been selling "https://" as secure, so we can't go back now and reeducate users. We should have decoupled the idea of security from the protocol used (https can be insecure) and used a separate channel entirely to communicate security, e.g. what browsers are doing now with padlocks or colour schemes. But it's too late to change the SSL UX.


Seems what Chrome is doing is a good idea. "Secure" is being phased out, then there will only be "insecure" for http, which it most certainly will be since there's no encryption.


The problem with client-side hashing in password forms is that the hash is now the password; as such, it provides no defense at all against even a passive attacker impersonating you. The only attack it provides any defense against is password reuse.


Not when the password is hashed with a nonce from the server.


This is digest encryption. While it's a great alternative to sending passwords in cleartext, it does have some major disadvantages.

> It prevents the use of a strong password hash (such as bcrypt) when storing passwords (since either the password, or the digested username, realm and password must be recoverable) [1]

Much better to have bcrypt'ed passwords stored on the server and your private SSL keys. If your compromised, revoke the SSL keys, and force users to change their passwords. With strong bcrypt'ed passwords, you can be reasonably sure passwords can't be recovered, but best to enforce resets anyways. With digested passwords, those will be recovered and end up in Troy Hunt's Pwned Passwords database.

[1] https://en.m.wikipedia.org/wiki/Digest_access_authentication...


Those disadvantages are based on the particular implementation. You could replace MD5 with bcrypt.


If we make perfect the enemy of good, there's no end to what we can filibuster to committee.


I can't help but wonder if we couldn't have used the CA system as a way to provide security for open wifi hotspots.

I know the CA system isn't perfect, but with the certificate transparency efforts it's pretty good. It would give me a trust point for the network I'm connecting to.


That won't work, setting aside how to get the coffee shops to do CA magement, how can a client know that momnpopshop.localcoffee.com is a valid cert for that access point, but momnpopshop.mallory.com isn't?

Opportunistic encryption without authentication is a major step up, and probably good enough for this scenario.


You could at least have Trust On First Use and rely on clients save the domain name<->SSID association. It stops someone from implementing a MITM on the network later on and is a significant improvement in security.

Having said that, there's no need for a CA as such to make that work.


Or publish SSID <-> public key association to a certificate transparency log. Or something like it...

Probably, SSIDs would need to be globally unique, or somehow couples with a GPS coordinate..


Couldn't home routers come with a certificate from the manufacturer?

I guess manufacturers could even issues certificates for globally unique SSIDs by allowing costumers to register a sub-domain with them. my-net.my-router.com

Yeah, dealing with CAs is probably overkill for local coffee shops and home networks.


Cisco Wireless Lan Controller came with a certificate so the access points knew they were connecting to a real Cisco device. It had an expiry date of 10 years. Which occurred for us a few months ago, and then after a power failure nothing would connect, fun times. Turned out you had to upgrade to the latest firmware, then disable the security check


It's more than imperfect it's practically useless in its current state. It provides exactly 0 proof of identity or trust. It's basically "oh, you're advertising an SSID with <name>? I'll connect to you and we can make up a trust after that".


It means that someone else in the area can't listen to your traffic and decrypt it, among other things. That might not be perfect, but it's far better than nothing.


It does that like putting a wad of money behind a window protects your cash. If I'm going to walk into Starbucks to sniff the guest wireless all WPA3 changes is I have to make my laptop advertise itself as "Google Starbucks" and you send me all of your traffic with an encryption key we both know.

People act like there is 0 harm in prematurely releasing a security feature in a network standard not remembering the various network hardware that will be made based on this don't follow a software development lifecycle where you just publish sprint 2 a few weeks from now with improvements and the world moves on. Even when things get updated wireless clients that are easily updatable (e.g. iOS/Windows devices) are only just recently using TLS 1.2 in their PEAP sessions. We shouldn't be playing fast and lose with security implementation in a future standard just because it sounds nice at first glance and assume sounds nice is better than nothing. What if we decide the next iteration of this design is to rely on PKI to create a chain of trust and now we've created 5 years of shit not working because wireless implementations are so shotty? Similar things have happened with other wireless standard revisions already... hell 802.11ac spent a lot of time and planning on MIMO (which is well established in other radio specifications already) and we still got an entire generation of wireless hardware that worked better without it enabled due to lack of real world vetting.

The best hope in this case is everyone realizes this doesn't provide any meaningful security in the current revision even though it's already available and being pranced around as a great security benefit.

/Rant of a network standards guy


That's just a case that it doesn't help with.

But—correct me if I'm wrong—it does help in the case where you have a home wifi network, that your devices all connect to, and remember the network. It will encrypt all the traffic of your devices. An attacker can't create a different network with the same SSID and trick existing devices to connect to it, right?

If I'm right, then this is quite valuable. It means that most home users can have an encrypted LAN without having to remember the password and tell all their guests what it is whenever they have a visitor.


> An attacker can't create a different network with the same SSID and trick existing devices to connect to it, right?

Can't he? Wouldn't the existing devices just try to connect to whatever broadcasts that SSID.


Some devices actually verify the MAC of the sender, but that’s probably the exception and not the rule.


That wouldn't help - Its trivial to configure an access point to advertise a user-selected MAC address, and the MAC address of an AP is broadcast in the clear even on WPA2 encrypted networks.


I think the parent post is referting to a Message Authentication Code not a mac address which an attacker couldn't forge.


The signal just has to be stronger and they will at some point.


As long as it's not presented as secure to users, I think it's a good thing.


I think it also protects against people injecting content into the stream such as with the (possibly acryphorial, but IMO hilarious) goatse attack at Defcon 12[0]. Yes, people can still impersonate the AP, but that attack takes a little more effort and hardware.

0: https://emaknyus.blogspot.com/2011/07/airpwn-bringing-goatse... (warning, likely contains goatse - image did not load for me)


I think you mean apocryphal?


Well, that's embarrassing... Past the edit window too.


Same. I run an open guest network, and have always thought it deserved more security. Nice to see that's coming.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: