A critical problem I see that needs solving is the Starbucks style open wifi login pages that fail to redirect when trying to visit HTTPS sites.
A new secure authentication system is needed for these set ups.
I’m blanking on the name of them but clearly they are widely deployed and likely causing lots of regular people to have trouble connecting to pages because they tried to connect to Facebook instead of an HTTP site.
Captive portals? Browsers and some mobile devices have a workaround where on new wifi connections they try to connect to a particular url and if that gives unexpected content they know it's a captive portal and prompt you to log in. But ideally this would be in the network descriptor somehow.
I have had this problem as well, and it became increasingly difficult to find non-https domains so I started using one of my own sub-domain for it (I needed it on the dutch railway system). But recently, Ubuntu added a captive portals catcher and gives a small browser window to login (I think it tries to contact an Ubuntu sub-domain first to test the connection, you can turn it off if you want). This is very handy!
Why is this a problem? Just mash some keys and add a .com to the end. The portal doesn't check if the domain is real or not, it just intercepts all DNS requests until you've logged in.
>A critical problem I see that needs solving is the >Starbucks style open wifi login pages that fail to redirect when trying to visit HTTPS sites.
The "fix" is to have automatic mechanisms that query a known-http page and detect a redirect. Which is what browsers already do. If you want to build your own system or don't want the browser to do the magic use neverssl.com.
> A new secure authentication system is needed for these set ups.
What would that mean to have "secure authentication" here? What are the security expectations of a "click here to get internet" system?
IMHO the best solution for captive portals would be to just not do them.
I would keep a wary eye open until actual specifications are announced and publicly available.
If history is any guide, some parts of it might become security mis-features, like Wi-Fi Protected Setup (WPS) which became a security issue because it allows WPS PIN recovery.
Also note that the IEEE controls the actual wireless specification as IEEE 802.11 and also specifies the actual encryption standards used during wireless transmission and reception (this used to be called IEEE 802.11i-2004 [1]).
My educated guess is that WPA3 won't change the block cyphers used to encrypt data (AES-CCMP) and the initial handshaking protocol as that is part of the IEEE Spec and cannot be changed by the Wi-Fi Alliance. Instead, it may specify additional requirements that clients have to fulfill before connecting (like public key certificates and proof of identities).
Where can I actually read the spec? I'm not even much of a cryptographer, but I'm curious --- and the closed attitude is a contributing factor to things like this:
Is WPA3 going to require new hardware (wifi client cards/chips, wifi routers) or will it be possible to add WPA3 support via a software update in common operating systems?
One feature I wish to see is some form of AP authentication, maybe with TOFU and some PK pinning. That is currently, name an AP the same as another and a machine that had the AP name saved will try to connect to it. If you name an AP "Apple Store" or "Starbucks" you can watch devices connect (with their real MAC even, defeating MAC randomization used when scanning for APs), and if it's an open AP or you got hold of the passphrase, monitor and possibly MITM connections.
We definitely need some kind of mechanism to authenticate APs, right now we only have the SSID and MAC, both of which are trivial to spoof.
There isn't even any collision detection, nothing stopping you from giving your AP the same SSID as an already present AP, and clients will helpfully connect to whichever one has the strongest signal, which is probably going to be the rogue AP right next to you, rather than the actual Starbucks AP at the other end of the store. According to 802.11, APs with identical names are considered to be part of the same network, no questions asked.
I consider it a fundamental flaw of wifi, alongside the boneheadedness of WEP ("wired equivalent protection"... Yeah right, pull the other one), and the idiotic layout of channels in the 2.4GHz spectrum.
The only way to use wifi as a consumer is with WPA2 (AES only, no TKIP) a randomly generated strong passkey, and all smart features turned way off (security holes such as WPS). For any AP that you haven't personally set up and vetted, and especially open public APs, a VPN connection is absolutely mandatory. And I still wouldn't trust it 100%.
> That is currently, name an AP the same as another and a machine that had the AP name saved will try to connect to it.
That's on purpose. At work, for instance, we have two APs with the same name, connected to the same wired network. A machine which originally was connected to one of them is supposed to try to connect to the other one when its signal is stronger. Break that mechanism, and you'll break all wifi networks larger than a few rooms.
I know this is on purpose and I use it myself to great extent, but provisioning each legit AP with an asymmetric key pair to be checked by the client proves this is one of the APs you intend to connect to, while still allowing for the roaming functionality.
Public areas could even physically display the AP's key fingerprint alongside the SSID (+ WPA key when not open).
> Another feature will strengthen user privacy in open networks through individualized data encryption.
WPA1 can arguably be forgiven a lot of shortcomings given its circumstances, but I never understood why this wasn't in WPA2. I understand that the station can't authenticate the AP in this case, but it still seems like it's strictly better for the traffic to be encrypted. What am I missing?
The same reason browsers don't allow self-signed certificates, I guess. Those security people think a false sense of security is worse than no security.
The false sense of security is what WPA2 gives anyway. Coffee house has a password on their wifi? Great, then only someone with the password can impersonate the AP, which is only... everyone.
You can't tell everybody something and still use it as a secret.
What they should be doing is putting the public key of the AP on the wall as a QR code.
Or the real solution, which is for everything to be end-to-end encrypted regardless.
If it’s inside a coffee shop or other physical locations the attempt is likely to be caught. Or, put the code inside a photo frame making it easier for staff to distinguish.
Perhaps they thought that this would be taken care of at a higher protocol layer. ISTR that things like IPSEC opportunistic encryption was hyped a lot at the time.
You can have per-device stream encryption with WPA2, just use 802.1x. If you accept any user/password you'll have a public wlan where people can't eavesdrop.
WPA-PSK already does this (per-device stream encryption). The per-stream encryption is specified during the four way handshake via the ANonce and SNonce values [1].
However, this is only true if the handshake is not intercepted or snooped on by a third party. If it is, then the attacker knows enough to decrypt your data.
802.1x provides extra protection by ensuring the initial PSK is not know to the attacker, making the initial snoop of the handshake ineffective.
Privacy Badger forces you to send the DNT header, making your browser far more vulnerable to fingerprinting. Just use the relevant filter lists in uBlock Origin.
Yes, because it's an option you specifically have to set as a user, most people don't bother (or don't know about it), so simply by setting the flag, you're making yourself easier to identify.
How does one do this? I found no relevant setting in privacy badger's settings, and even though dnt is disabled in my browser's settings, I'm still sending the dnt header with privacy badger on (after disabling Privacy Badger my browser no longer sends it, so it's definitely Privacy Badger).
The settings say that DNT is either always on or on when using tracking protection. So do you have tracking protection off and rely on uBlock instead? (I don't use privacy badger.)
According to that site, I also have DNT enabled, however https://amiunique.org/fp says it is off ("NC" == not set).
I have tracking protection in Firefox set to off, as it uses the same Disconnect.me lists that you can enable in uBlock Origin. I guess Privacy Badger just forces through DNT, as per EFF's stance on the matter. I think it's somewhat counterproductive.
Nonetheless, DNT on/off is absolutely secondary to simply blocking all tracking through uBO and Privacy Badger.
Either NC doesn't mean what you think it means or the website is wrong. It says NC for me too, but I can clearly see the header being sent in both dev tools and in wireshark.
CNSA isn't an algorithm. It's the NSA's update to what used to be called "Suite B". It's a set of algorithms that NSA recommends for use in National Security Systems (classified systems that use unclassified algorithms).
Currently, that's AES-256, ECDH over P-384, ECDSA over P-384, SHA-384, and then also RSA/DH with a >3072 modulus.
Which of the above do you think are "NSA-designed algorithms"?
The real NSA algorithms are part of "Suite A", which you don't have to worry about trusting because they aren't public. (I've chosen not to use things like the NIST curves for ECDSA, though.)
Thanks, it was mostly a rhetorical question for the user who seems to think that the NSA designed all of them. (For some reason, I've met a lot of people who think NSA designed AES, for example.)
A new secure authentication system is needed for these set ups.
I’m blanking on the name of them but clearly they are widely deployed and likely causing lots of regular people to have trouble connecting to pages because they tried to connect to Facebook instead of an HTTP site.