I spent a long time in the past couple of years trying to work out how to deploy secure WiFi and failed to come up with anything great. The biggest challenge is that client support for anything beyond wpa2 psk is virtually nonexistent. The Hotspot 2.0 spec is supposed to make all this easier but it's not widely supported and heavily influenced by carriers whose goals don't always align with everyone else in the space.
Care to elaborate on the client support? AFAIK, all major operating systems support WPA Enterprise (I've used it with Mac, Linux, Windows, iOS and Android).
Unlike WPA PSK, all of the real-world-usable EAP methods used in IEEE 802.1X EAPOL ("WPA Enterprise") require client authentication, which must be provisioned out-of-band. Thus, effectively, they cannot be used for such deployments being discussed.
For example, EAP-TLS, unlike the TLS used in HTTPS, requires a client to provide a X.509 certificate signed by an AP-side trusted authority. This is because people like Jouni Malinen (hostapd/wpa_supplicant), in all their wisdom, decided to spurn RFC 5216 ("While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances...") and completely disallow any and all configuration to disable the client-cert requirement, regardless of any circumstances (such as those behind HTTPS). NYC DoITT is no more equipped to provision X.509 certs for free wifi users than the NYS DMV is to provision X.509 certs for $80 DL/ID card holders (so people can securely prove their identity everywhere).
As trollian stated, Wi-Fi Alliance's "Passpoint" (Hotspot 2.0) does allow for such setups, technically. E.g., the vendor-specific WFA-UNAUTH-TLS version of EAP-TLS does not do client-side authentication at the WPA-level, as per RFC 5216. But WFA-UNAUTH-TLS, even among Passpoint-aware devices, is likely not widely supported.
> Unlike WPA PSK, all of the real-world-usable EAP methods used in IEEE 802.1X EAPOL ("WPA Enterprise") require client authentication, which must be provisioned out-of-band. Thus, effectively, they cannot be used for such deployments being discussed.
I'm not convinced that is really true. Sure, some sort of client authentication is technically required, but I think you can configure the authentication server to accept any authentication without compromising the link security. Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.
> Sure, some sort of client authentication is technically required, but I think you can configure the authentication server to accept any authentication without compromising the link security.
It this supported anywhere? Hence the mention of HS2.0 and my jab at Jouni. (In Jouni's defense, hostapd has made really good progress on this.)
> Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.
This may be supported by Hotspot 2.0 Release 2 (IEEE 802.11u) Online Sign Up (OSU) Server-Only Authenticated L2 Encryption Network (OSEN). I would like to know if OSEN is usable for this scenario.
>> configure the authentication server to accept any authentication
> It this supported anywhere?
Yes. FreeRADIUS can do it. The clients don't notice. I've seen it work. The configuration is a bit tricky though. Not sure about hostapds radius server.
I've seen it in place at the Chaos Communication Congress in 2014, I used it with a couple of clients without issues. Not sure what was used or how much effort the configuration was.
Here is a nice write-up on how 802.11x security was provided to attendees at 32C3 (they used TTLS with no client certs and users could choose their own user/passwords anonymously)
It authenticates by checking that AP knows shared password. If that password is known by attackers, i.e. the network contains at least one malicious node, then that procedure is useless.
Article is completely wrong about not being able to decrypt other clients traffic when the PSK is known to the malicious actor and the authentication handshake is able to be observed.
This is well known and even documented in wiresharks guides.
see Gotchas -> "WPA and WPA2 use keys derived from an EAPOL handshake,..." https://wiki.wireshark.org/HowToDecrypt802.11
Does anyone here know much about Hotspot 2.0 Release 2 (IEEE 802.11u) Online Sign Up (OSU) Server-Only Authenticated L2 Encryption Network (OSEN)? OSEN seems like it would be perfect for a setup like LinkNYC.
So yes it looks like the "LinkNYC Private" network is indeed using full-blown WPA2-Enterprise IEEE 802.1X EAP-TLS w/ client certs.
It looks to be using Wi-Fi Passpoint "online sign up" (OSU) setup for client cert provisioning. Unfortunately, it does NOT look like it uses OSEN (WFA-UNAUTH-TLS type EAP-TLS) for the OSU WLAN, but instead chooses the option for an open OSU WLAN (using the same SSID as the non-private network) with a HTTPS captive portal. I would assume that this is the mechanism behind the reports of certificate downloads on iPhones.
Not just that, but not all 802.1x methods actually provide mutual authentication either. In order to avoid this attack, the user device needs to authenticate the access point (and keys have to be distributed somehow!) At the very least, ensuring that an access point is the same access point as it was before, which would mitigate spoofing.
Authentication in one direction (or lack of authentication entirely) is what leads to this attack, since the fake access point can just say "OK" to anybody trying to connect.
I don't understand why one would care about this. What is the difference between the provider snooping your traffic and a 'hacker'? Do people really believe there is any kind of privacy on these networks?
The internet is not trustworthy. It doesn't matter how you connect to it.
22 comments
[ 3.0 ms ] story [ 58.5 ms ] threadFor example, EAP-TLS, unlike the TLS used in HTTPS, requires a client to provide a X.509 certificate signed by an AP-side trusted authority. This is because people like Jouni Malinen (hostapd/wpa_supplicant), in all their wisdom, decided to spurn RFC 5216 ("While the EAP server SHOULD require peer authentication, this is not mandatory, since there are circumstances...") and completely disallow any and all configuration to disable the client-cert requirement, regardless of any circumstances (such as those behind HTTPS). NYC DoITT is no more equipped to provision X.509 certs for free wifi users than the NYS DMV is to provision X.509 certs for $80 DL/ID card holders (so people can securely prove their identity everywhere).
As trollian stated, Wi-Fi Alliance's "Passpoint" (Hotspot 2.0) does allow for such setups, technically. E.g., the vendor-specific WFA-UNAUTH-TLS version of EAP-TLS does not do client-side authentication at the WPA-level, as per RFC 5216. But WFA-UNAUTH-TLS, even among Passpoint-aware devices, is likely not widely supported.
I'm not convinced that is really true. Sure, some sort of client authentication is technically required, but I think you can configure the authentication server to accept any authentication without compromising the link security. Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.
It this supported anywhere? Hence the mention of HS2.0 and my jab at Jouni. (In Jouni's defense, hostapd has made really good progress on this.)
> Or you could auto-provision users on first login or something like that depending on what sort of access you want to give.
This may be supported by Hotspot 2.0 Release 2 (IEEE 802.11u) Online Sign Up (OSU) Server-Only Authenticated L2 Encryption Network (OSEN). I would like to know if OSEN is usable for this scenario.
> It this supported anywhere?
Yes. FreeRADIUS can do it. The clients don't notice. I've seen it work. The configuration is a bit tricky though. Not sure about hostapds radius server.
I've seen it in place at the Chaos Communication Congress in 2014, I used it with a couple of clients without issues. Not sure what was used or how much effort the configuration was.
http://mobilesociety.typepad.com/mobile_life/2016/01/wifi-ce...
This is well known and even documented in wiresharks guides. see Gotchas -> "WPA and WPA2 use keys derived from an EAPOL handshake,..." https://wiki.wireshark.org/HowToDecrypt802.11
It looks to be using Wi-Fi Passpoint "online sign up" (OSU) setup for client cert provisioning. Unfortunately, it does NOT look like it uses OSEN (WFA-UNAUTH-TLS type EAP-TLS) for the OSU WLAN, but instead chooses the option for an open OSU WLAN (using the same SSID as the non-private network) with a HTTPS captive portal. I would assume that this is the mechanism behind the reports of certificate downloads on iPhones.
LinkNYC and Hotspot 2.0:
https://medium.com/@LinkNYC/secure-browsing-on-linknyc-s-wi-...
https://www.globalreachtech.com/deployments/link-nyc/
Wi-Fi Passpoint aka Hotspot 2.0:
https://www.wi-fi.org/downloads-public/Passpoint_R2_Deployme...
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2...
Reports of cert provisioning:
http://blog.alexflor.es/post/137705262900/linknyc-secure-gig...
http://www.engadget.com/2016/01/19/linknyc-gigabit-wifi-hand...
Authentication in one direction (or lack of authentication entirely) is what leads to this attack, since the fake access point can just say "OK" to anybody trying to connect.
The internet is not trustworthy. It doesn't matter how you connect to it.