Hide Forgot
+++ This bug was initially created as a clone of Bug #1462262 +++ From: https://bugzilla.redhat.com/show_bug.cgi?id=1453066 --- Comment #36 from Tomas Mraz <tmraz@redhat.com> --- If wpa_supplicant by default uses 'DEFAULT:!EXP:!LOW', it still will not work. Please open a new bug against wpa_supplicant and link it to this bug. I'd suggest that the wpa_supplicant should not set any ciphersuite string by default or use PROFILE=SYSTEM ciphersuite string (these are equivalent). --- Additional comment from Steven Haigh on 2017-06-24 14:49:47 EST --- Just wondering if I could give this a nudge... This may have a wider impact on schools / unis etc that use WPA2 Enterprise authenticated networks... Problem is, once you install, you can't connect to certain WPA2 Enterprise networks - meaning you can't easily get updates if this is resolved *after* F26 final is released... --- Additional comment from Beniamino Galvani on 2017-06-26 19:49 EST --- I sent a patch upstream [1] to allow the selection of the default cipher list at build time. The attached dist-git patch (which includes [1]) builds the Fedora package with PROFILE=SYSTEM. However, note that the solution is still sub-optimal, because: 1. users that needed 3DES in wpa_supplicant and upgrade from F25 have to manually run 'update-crypto-policies --set LEGACY' 2. this decreases the security for the whole system Any opinions? [1] http://lists.infradead.org/pipermail/hostap/2017-June/037734.html --- Additional comment from Steven Haigh on 2017-06-26 20:01:25 EST --- Adding tmraz for possible insight. --- Additional comment from Steven Haigh on 2017-06-26 20:06:54 EST --- I'm not exactly sure what the best way forward is - considering Fedora is currently the odd one out. The cipher is currently enabled in: * Android * iOS * OSX * Windows 7 through 10. As such, these clients connect out of the box (after GTC support is added to Windows). It also means there is no precedence in what should be done here. Is documentation of the required steps enough? Problem is, if you're stuck with this as your only connections - how do you read that? Do we have enough information to add a workaround case? ie detect there has been a failure, diagnose it, and maybe prompt to use 'legacy' ciphers? --- Additional comment from Tomas Mraz on 2017-06-26 21:10:20 EST --- The other option is to use PROFILE=SYSTEM:3DES for wpa_supplicant. This way the configuration still tries to follow the Fedora crypto policy settings but it will enable to work with legacy systems out of the box. --- Additional comment from Beniamino Galvani on 2017-06-26 21:43:20 EST --- I just realized that the DEFAULT crypto-policy already includes 3DES-CBC-SHA on F26: root@f26 ~ # update-crypto-policies --set DEFAULT Setting system policy to DEFAULT root@f26 ~ # openssl ciphers -V PROFILE=SYSTEM | grep 0x00,0x0A 0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 I assumed that the DEFAULT crypto-policy was the same as the OpenSSL DEFAULT cipher list, but this is not true. So please, ignore the two points in comment 2. With the patch, everything should work out of the box on F26. Steven, can you confirm that the authentication works with the updated openssl package using the following wpa_supplicant configuration on F26? network={ ssid="<SSID>" scan_ssid=1 key_mgmt=WPA-EAP password="<password>" eap=PEAP fragment_size=1266 phase2="auth=GTC" ca_cert="/etc/pki/tls/certs/ca-bundle.trust.crt" identity="<username>" openssl_ciphers="PROFILE=SYSTEM" } --- Additional comment from Steven Haigh on 2017-06-27 12:45:48 EST --- Hi all, Still doesn't seem to be happy: # wpa_supplicant -i wlp2s0 -c wpas.conf Successfully initialized wpa_supplicant wlp2s0: SME: Trying to authenticate with 04:bd:88:ba:e1:31 (SSID='<SSID>' freq=5785 MHz) wlp2s0: Trying to associate with 04:bd:88:ba:e1:31 (SSID='<SSID>' freq=5785 MHz) wlp2s0: Associated with 04:bd:88:ba:e1:31 wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp2s0: CTRL-EVENT-DISCONNECTED bssid=04:bd:88:ba:e1:31 reason=3 locally_generated=1 wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=AU wlp2s0: SME: Trying to authenticate with 04:bd:88:bb:05:91 (SSID='<SSID>' freq=5745 MHz) wlp2s0: Trying to associate with 04:bd:88:bb:05:91 (SSID='<SSID>' freq=5745 MHz) wlp2s0: Associated with 04:bd:88:bb:05:91 wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp2s0: CTRL-EVENT-DISCONNECTED bssid=04:bd:88:bb:05:91 reason=3 locally_generated=1 wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=AU wlp2s0: SME: Trying to authenticate with 04:bd:88:ba:e1:21 (SSID='<SSID>' freq=2412 MHz) wlp2s0: Trying to associate with 04:bd:88:ba:e1:21 (SSID='<SSID>' freq=2412 MHz) wlp2s0: Associated with 04:bd:88:ba:e1:21 wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp2s0: CTRL-EVENT-DISCONNECTED bssid=04:bd:88:ba:e1:21 reason=3 locally_generated=1 wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=AU wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=USER type=COUNTRY alpha2=AU wlp2s0: SME: Trying to authenticate with 04:bd:88:bb:05:82 (SSID='<SSID>' freq=2437 MHz) ^Cnl80211: deinit ifname=wlp2s0 disabled_11b_rates=0 wlp2s0: CTRL-EVENT-TERMINATING I tried with the following: openssl_ciphers="PROFILE=SYSTEM" openssl_ciphers="PROFILE=SYSTEM:3DES" I also tried with ca_cert="" just in case there is a problem with cert validation. Still no success. Do you need a new packet dump of this with the new openssl / config? --- Additional comment from Beniamino Galvani on 2017-06-27 18:41:14 EST --- Hm, I don't know why EAP doesn't even start now. If the problem was in the TLS handshake I would have expected something like: https://bugzilla.redhat.com/show_bug.cgi?id=1453066#c20 Was NM stopped? Can you try with the configuration from the link, only replacing "openssl_ciphers"? And, yes, a packet dump would be useful too, thanks! --- Additional comment from Steven Haigh on 2017-06-27 18:47:56 EST --- I apologise! I forgot to set the wifi adapter as unmanaged before my test! # nmcli device set wlp2s0 managed no # wpa_supplicant -i wlp2s0 -c wpas.conf Successfully initialized wpa_supplicant wlp2s0: SME: Trying to authenticate with 04:bd:88:ba:e1:31 (SSID='<SSID>' freq=5240 MHz) wlp2s0: Trying to associate with 04:bd:88:ba:e1:31 (SSID='<SSID>' freq=5240 MHz) wlp2s0: Associated with 04:bd:88:ba:e1:31 wlp2s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0 wlp2s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=AU wlp2s0: CTRL-EVENT-EAP-STARTED EAP authentication started wlp2s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13 -> NAK wlp2s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25 wlp2s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected <cert details> EAP-TLV: TLV Result - Success - EAP-TLV/Phase2 Completed wlp2s0: CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully wlp2s0: WPA: Key negotiation completed with 04:bd:88:ba:e1:31 [PTK=CCMP GTK=CCMP] wlp2s0: CTRL-EVENT-CONNECTED - Connection to 04:bd:88:ba:e1:31 completed [id=0 id_str=] This looks *much* better. This was using the string: openssl_ciphers="PROFILE=SYSTEM" Without the above line, the problem persisted. --- Additional comment from Tomas Mraz on 2017-06-27 21:03:59 EST --- I'd suggest using openssl_ciphers="PROFILE=SYSTEM:3DES" as future proof default for at least some time. The reason is that the default system profile might loose the 3DES support in next Fedora release or so. 3DES is not safe and not needed anymore for general TLS use. --- Additional comment from Steven Haigh on 2017-06-27 21:09:13 EST --- So the issue now, does this get changed as the default in wpa_supplicant? or as a call to it from NetworkManager? --- Additional comment from Beniamino Galvani on 2017-06-27 22:04:28 EST --- (In reply to Tomas Mraz from comment #10) > I'd suggest using openssl_ciphers="PROFILE=SYSTEM:3DES" as future proof > default for at least some time. The reason is that the default system > profile might loose the 3DES support in next Fedora release or so. 3DES is > not safe and not needed anymore for general TLS use. OK, makes sense to me. (In reply to Steven Haigh from comment #11) > So the issue now, does this get changed as the default in wpa_supplicant? or > as a call to it from NetworkManager? The plan is to set it as default in wpa_supplicant. NM doesn't set the openssl_ciphers option when calling wpa_supplicant. --- Additional comment from Dan Williams on 2017-06-28 07:18:48 EST --- LGTM; If for some reason upstream rejects the patch I guess we can always patch NM to pass the openssl_ciphers config option in the network block. But I agree that the supplicant should use distro defaults rather than hardcoding a fallback. --- Additional comment from Steven Haigh on 2017-07-10 14:45:32 EST --- Just wanted to give this a nudge. We missed the F26 release, but having it as a near-to-release update would be nice. --- Additional comment from Fedora Update System on 2017-07-18 05:10:39 EST --- wpa_supplicant-2.6-8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c3438ec82a --- Additional comment from Steven Haigh on 2017-07-18 11:17:35 EST --- I can confirm that this issue is resolved with wpa_supplicant-2.6-8.fc26. Karma left on the bodhi page. --- Additional comment from Fedora Update System on 2017-07-20 10:25:12 EST --- wpa_supplicant-2.6-8.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-c3438ec82a --- Additional comment from Fedora Update System on 2017-07-21 01:53:59 EST --- wpa_supplicant-2.6-8.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report. --- Additional comment from Przemyslaw Szypowicz on 2017-08-14 21:21:05 EST ---
Hi all, I believe this issue has resurfaced in the current F28 Beta. I'm unable to connect to our WPA2 Enterprise networks again.
Just want to give this issue a nudge. I am still unable to connect to a couple of WPA2 Enterprise networks with F28.
Can you try changing the crypto policy with: update-crypto-policies --set LEGACY ? See also [1]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1570402#c1
I can confirm that 'update-crypto-policies --set LEGACY' then 'systemctl restart NetworkManager' allows me to connect to the WPA2 Enterprise network now. Is this a direction that is set? or will this end in re-enabling a couple of common ciphers that are everywhere for compatibility reasons?
(In reply to Steven Haigh from comment #4) > I can confirm that 'update-crypto-policies --set LEGACY' then 'systemctl > restart NetworkManager' allows me to connect to the WPA2 Enterprise network > now. wpa_supplicant uses "PROFILE=SYSTEM:3DES" as the ciphers list. PROFILE=SYSTEM is determined by the currently active crypto policy. By default on Fedora 28 it is: # cat /usr/share/crypto-policies/DEFAULT/openssl.txt kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!aDSS:!EXP:!3DES:!DES:!RC4:!RC2:!IDEA:!SEED:!eNULL:!aNULL:!MD5:!SSLv2:!ADH Note the "!3DES". According to "man ciphers": If ! is used then the ciphers are permanently deleted from the list. The ciphers deleted can never reappear in the list even if they are explicitly stated. So, the 3DES we add to PROFILE=SYSTEM has no effect. I guess it is a deliberate choice to disable algorithms considered broken. > Is this a direction that is set? or will this end in re-enabling a couple of > common ciphers that are everywhere for compatibility reasons? I don't know. I'm reassigning this to crypto-policies so that maintainers can answer your questions.
For now please use the 'update-crypto-policies --set LEGACY'. But yes, we should fix crypto-policies to use '-' instead of '!' for at least some of the legacy ciphers.