Bug 1564336 - use '-3DES' instead of '!3DES' in openssl crypto policy so it can be readded for WPA2 Enterprise
Summary: use '-3DES' instead of '!3DES' in openssl crypto policy so it can be readded ...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: crypto-policies
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Red Hat Crypto Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1591620
TreeView+ depends on / blocked
 
Reported: 2018-04-06 01:16 UTC by Steven Haigh
Modified: 2018-08-01 09:16 UTC (History)
13 users (show)

Fixed In Version: crypto-policies-20180730-1.git9d9f21d
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1462262
Environment:
Last Closed: 2018-08-01 09:16:49 UTC
Type: Bug


Attachments (Terms of Use)

Description Steven Haigh 2018-04-06 01:16:36 UTC
+++ 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 ---

Comment 1 Steven Haigh 2018-04-06 01:17:38 UTC
Hi all,

I believe this issue has resurfaced in the current F28 Beta.

I'm unable to connect to our WPA2 Enterprise networks again.

Comment 2 Steven Haigh 2018-05-07 01:08:49 UTC
Just want to give this issue a nudge. I am still unable to connect to a couple of WPA2 Enterprise networks with F28.

Comment 3 Beniamino Galvani 2018-05-07 06:29:21 UTC
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

Comment 4 Steven Haigh 2018-05-07 07:14:35 UTC
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?

Comment 5 Beniamino Galvani 2018-05-07 11:54:07 UTC
(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.

Comment 6 Tomas Mraz 2018-05-08 13:15:06 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.