7 ms·

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

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."

wpietri 8y ago
Same. I run an open guest network, and have always thought it deserved more security. Nice to see that's coming.
stephengillie 8y ago
If we make perfect the enemy of good, there's no end to what we can filibuster to committee.
zamadatix 8y ago
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".
- DuskStar 8y ago
  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.
  - jake_the_third 8y ago
    As long as it's not presented as secure to users, I think it's a good thing.
    - DuskStar 8y ago
      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-and-friends-to.html https://emaknyus.blogspot.com/2011/07/airpwn-bringing-goatse... (warning, likely contains goatse - image did not load for me)
      - rrdharan 8y ago
        I think you mean apocryphal?
        DuskStar 8y ago
        Well, that's embarrassing... Past the edit window too.
  - zamadatix 8y ago
    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
    - toomim 8y ago
      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.
      - konschubert 8y ago
        > 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.
lucb1e 8y ago
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?)
- nothrabannosir 8y ago
  > Same with https errors… That's a branding issue: we've been selling "https://" 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.
  - jazoom 8y ago
    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.
- ameliaquining 8y ago
  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.
  - jenscow 8y ago
    Not when the password is hashed with a nonce from the server.
    - move-on-by 8y ago
      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#Disadvantages https://en.m.wikipedia.org/wiki/Digest_access_authentication...
jopsen 8y ago
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.
- dtech 8y ago
  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.
  - tomatocracy 8y ago
    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.
    - jopsen 8y ago
      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..
  - jopsen 8y ago
    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.
    - mavhc 8y ago
      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

wpietri 8y ago

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

stephengillie 8y ago

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

zamadatix 8y ago

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".

DuskStar 8y ago
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.
- jake_the_third 8y ago
  As long as it's not presented as secure to users, I think it's a good thing.
  - DuskStar 8y ago
    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-and-friends-to.html https://emaknyus.blogspot.com/2011/07/airpwn-bringing-goatse... (warning, likely contains goatse - image did not load for me)
    - rrdharan 8y ago
      I think you mean apocryphal?
      - DuskStar 8y ago
        Well, that's embarrassing... Past the edit window too.
- zamadatix 8y ago
  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
  - toomim 8y ago
    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.
    - konschubert 8y ago
      > 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.

lucb1e 8y ago

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

nothrabannosir 8y ago
> Same with https errors… That's a branding issue: we've been selling "https://" 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.
- jazoom 8y ago
  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.
ameliaquining 8y ago
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.
- jenscow 8y ago
  Not when the password is hashed with a nonce from the server.
  - move-on-by 8y ago
    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#Disadvantages https://en.m.wikipedia.org/wiki/Digest_access_authentication...

jopsen 8y ago

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.

dtech 8y ago
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.
- tomatocracy 8y ago
  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.
  - jopsen 8y ago
    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..
- jopsen 8y ago
  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.
  - mavhc 8y ago
    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