Hide Forgot
Description of problem: After upgrading to fedora 33 I am unable to connect to certain wifi acces points. Specificaly I can't connect to eduroam (https://en.wikipedia.org/wiki/Eduroam) eduroam, eduroam uses PEAP and MSCHAvP2 and WPA2 Enterprise. I looked at the logs and I suspect wpa_supplicant is the culprit, tho my knowlegde fails me here. I set this to low severity but for me this is extremely problematic. Version-Release number of selected component (if applicable): wpa_supplicant:2.9-6 How reproducible: Very Steps to Reproduce: 1. Install fedora 33 2. Try to connect to eduroam (or something similair) 3. Weep Actual results: No connection with eduroam Expected results: Connection with eduroam Additional info:
Can you please try the commands described in [1] to change the system crypto policy? [1] https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2#Upgrade.2Fcompatibility_impact
Yes will do, Using: update-crypto-policies --set DEFAULT:FEDORA32 Then restarting resolved the problem for me, thank you
I can confirm this happens to me too when connecting to eduroam. It worked fine on Fedora 32. In systemctl status wpa_supplicant this was reported: wpa_supplicant[986]: dbus: wpa_dbus_property_changed: no property SessionLength in object /fi/w1/wpa_supplicant1/Interfaces/2 --- update-crypto-policies fixed the issue for me
I believe this is expected due to the deprecation of weak crypto protocols, but I'm reassigning the bug to crypto-policies for a confirmation.
It would be interesting to see if there is anything more in the logs. By itself these protocols should not be disabled but perhaps TLS-1.0 is used in the EAP-TLS in your case.
*** Bug 1893211 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
The same happens in fedora 35
Indeed, the problem is due to the deprecation of obsolete protocols (and some enterprise servers have not been updated as of today). The solution I adopted is to run update-crypto-policies --set LEGACY even if this alters all policies related to SSL (both OpenSSL and GNUssl). It would be nice if it were possible to have a finer control (per application?) of where the policies are applied (as to limit the change to wpa-supplicant).
The narrowest crypto-policies can go now is roughly per-library, see `man crypto-policies`, this new feature is called "scopes". That being said, crypto-policies aims to set defaults, so the applications should be able to override whatever it sets. But then that's on the application to expose controls for it.
I'm afraid the answer is "ask your local network administrators to update to newer crypto", with a workaround of LEGACY or custom policy. There is an unsupported way to change crypto-policies per-process (see bz2064740), so wrapping wpa-supplicant might also be an option. I don't think it's worth it to generate separate configs for wpa-supplicant.