WPA3 Wifi Security Protocol Announced
wi-fi.org
wi-fi.org
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.
The website is fast, light (to say the least), always up, the URL is short and there is no valid HTTPS version so no need to type http://.
It also makes people around smile (and ask what this website is while I'm testing stuff and not thinking about it). English translation:
Lost on the Internet?
Don't panic, we are going to help you
* <----- you are here
In 2016, perdu.com was displayed 1-2 million times per day and his author was spending €65 per year for this (source: https://www.nouvelobs.com/rue89/rue89-internet/20160603.RUE3...).
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.
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).
https://blog.cryptographyengineering.com/2017/10/16/falling-...
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%.
It's more of an implementation and UI problem. The required standards already exist, no need to wait for WPA3.
[1] https://en.wikipedia.org/wiki/IEEE_802.11u#EAP-TLS
[2] https://web.archive.org/web/20131126183610/http://riosec.com...
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.
Public areas could even physically display the AP's key fingerprint alongside the SSID (+ WPA key when not open).
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?
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'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.
Except if the attacker has his own QR code stickers.
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.
I'm on Firefox 57, also using uBlock Origin with every tracking-related filter list (I presume that may make a difference).
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.)
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.
Currently, that's AES-256, ECDH over P-384, ECDSA over P-384, SHA-384, and then also RSA/DH with a >3072 modulus.
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.)