Around a month or two ago, I was helping a user in #gentoo who was having trouble connecting to a wifi network that had both WPA (TKIP) and WPA2 (CCMP) support enabled. Enabling TKIP support in wpa_supplicant resolved the issue. Last week, I was chatting with ulm in IRC, and a similar issue came up. He was using NetworkManager, and his mixed-mode WPA/WPA2 networks at a university were not showing up in the network list. Enabling the 'tkip' USE flag resolved the issue. Based on these two incidents, it seems like the CONFIG_NO_TKIP option doesn't just disable using TKIP for connections, but actually prevents one from connecting to any network that (optionally) supports TKIP, even if said network also supports CCMP. Given this non-intuitive behavior, I think the tkip USE flag should be enabled by default.
The comments in the commit below sort of imply that mixed-mode WPA/WPA2 networks need TKIP support to be enabled. https://w1.fi/cgit/hostap/commit/?h=6b1c590ebb87bd4ddd2930feb621f463197d1125
https://www.wi-fi.org/download.php?file=/sites/default/files/private/Wi-Fi_Alliance_Technical_Note_TKIP_v1.0.pdf TKIP was *removed* from the wifi alliance certification and is forbidden on all devices since mid-2015. Microsoft also sunset tkip in 2019 https://meterpreter.org/windows-10-no-longer-supports-wifi-wep-tkip/ Please, I think leaving the flag to enable a broken and vulnerable protocol was more than enough for users who *must* connect to these non-compliant networks. Let's not make insecurity the new Gentoo default.
I wouldn't call this FIXED, but WONTFIX is a valid response.
https://windows11central.com/en/windows-11-will-no-longer-support-wep-and-wpa-wpa2-tkip-encryption/ Per microsoft's official site, it appears they have not completely removed support, only deprecated it: https://docs.microsoft.com/en-us/windows/deployment/planning/windows-10-deprecated-features The preview builds with it disabled don't appear to have brought that "feature" to mainstream yet. Still, I'm pretty happy with the Gentoo default being secure.
The problem is that wpa_supplicant refuses to connect to any access point that offers both TKIP and CCMP, even if that connection would be with CCMP. In other words, the access point merely offering TKIP for backwards compatibility also prevents connections in the more secure mode. In fact, these access points won't show up in NetworkManager's list at all. IMHO this is not a reasonable default. I don't want connections using TKIP, but I want to be able to connect to a network via CCMP even if that network offers TKIP as an alternative. There seems to be no way to express that preference: With -tkip I cannot connect to such networks at all, so the only thing I can do is to enable the flag which will allow insecure connections.
From #gentoo-dev: """ <@floppym> Are you certain it will use TKIP in the case of a network that supports both TKIP and CCMP? <@floppym> That doesn't sound right to me. <@Zero_Chaos> if the network allows both, you have to use the weaker for the group key or the tkip only devices can't decode broadcast/multicast <@iamben> so connecting to wpa2-aes on a mixed mode network is literally the same as using wpa-tkip? <@Zero_Chaos> iamben: wifi uses two keys, a unicast key and a broadcast/multicast "group" key. <@Zero_Chaos> iamben: for the unicast key, you get the best you support. but the group key is literally shared, so you have to use the weakest <@iamben> Zero_Chaos: but that's not the same risk as using tkip for the unicast key, right? <@Zero_Chaos> iamben: it still is. two packet DoS, easily crackable key, frame injection of unicast packets using group key. """ Based on this conversation I conclude: 1. There is no way to avoid using TKIP on a network that supports both TKIP and CCMP. 2. Using TKIP exposes the user to some security holes. It would be nice to somehow enhance wpa_supplicant and/or NetworkManager to make this more obvious to the user, but that's outside the scope of this bug report.
*** Bug 888071 has been marked as a duplicate of this bug. ***
*** Bug 836423 has been marked as a duplicate of this bug. ***
I discovered this also stops you from setting up a nmcli wifi hotspot, unless you explicitly configure CCMP everywhere. Took a few hours to arrive at :/
