From: https://bugzilla.redhat.com/show_bug.cgi?id=1453066 --- Comment #36 from Tomas Mraz <tmraz> --- 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).
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...
Created attachment 1291939 [details] [dist-git PATCH] OpenSSL: use system ciphers by default (rh#1462262) 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
Adding tmraz for possible insight.
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?
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.
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" }
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?
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!
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.
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.
So the issue now, does this get changed as the default in wpa_supplicant? or as a call to it from NetworkManager?
(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.
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.
Just wanted to give this a nudge. We missed the F26 release, but having it as a near-to-release update would be nice.
wpa_supplicant-2.6-8.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-c3438ec82a
I can confirm that this issue is resolved with wpa_supplicant-2.6-8.fc26. Karma left on the bodhi page.
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
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.
*** Bug 1470611 has been marked as a duplicate of this bug. ***