Arch Linux

More details in https://bbs.archlinux.org/viewtopic.php?id=286417

OpenSSL 3.1 banned SSL3, TLS1, TLS1.1 and DTLS1.0 at security level one and above [1].
This breaks autodection of when to downgrade security level [2] as the connection has now already been rejected. Applying [3] has no effect the connection has still already been rejected.
wpa_suplicant does support explicitly allowing TLS1.1 and TLS1 [4] which was tested to work [5][6].

[1] https://github.com/openssl/openssl/commit/a8b6c9f83ce49b6192137c7600532441db885e19
[2] https://gitlab.archlinux.org/archlinux/packaging/packages/wpa_supplicant/-/blob/main/lower_security_level_for_tls_1.patch
[3] https://w1.fi/cgit/hostap/commit/?id=e9b4ad2364c68130c7618a88a171e29e0e15007e
[4] https://w1.fi/cgit/hostap/commit/?id=58bbcfa31b18eae42e3f3dc8fea716360d4bb67f
[5] https://bbs.archlinux.org/viewtopic.php?pid=2104698#p2104698
[6] https://bbs.archlinux.org/viewtopic.php?pid=2104709#p2104709

@loqs, thanks for the detailed research and links! IIUC this is not a bug in openssl and is in fact intended behavior. It seems more like a config issue in wpa_supplicant and should therefore be documented in the Wiki.

Is there anything for Arch to fix package-wise? Does anything need to be reported upstream?

I think upstream wpa_supplicant should be notified to see if lower_security_level_for_tls_1.patch which is upstream commit [1] bc99366f9b960150aa2e369048bbc2218c1d414e can be reworked to be compatible with OpenSSL 3.1.
The wpa_supplicant package could drop applying the patch as it no longer has any effect although leaving it is harmless. The wpa_supplicant_tls.patch is also made redundant as manually enabling TLS1.1 or TLS1 in wpa_supplicant's config sets the matching minimum protocol level along with the security level. Leaving it has no effect with OpenSSL now enforcing a TLS1.2 minimum by default.

[1] https://w1.fi/cgit/hostap/commit/?id=bc99366f9b960150aa2e369048bbc2218c1d414e

Thanks again @loqs. Ok, then someone who is motivated needs to report this to wpa_supplicant upstream. It's not an Arch packaging bug...but I will notify the wpa_supplicant PM's just in case.

Could you try https://pkgbuild.com/~heftig/FS%2378770/ ?

@heftig I tried that package but nothing changed, wifi could not connect.

I reported the problem the wpa_supplicant maintainer. I'll get back when he replies back.

I think I see the same issue:
```
$ sudo wpa_supplicant -P /run/wpa_supplicant-wlan0.pid -i wlan0 -D nl80211,wext -c/tmp/test.conf
Successfully initialized wpa_supplicant
wlan0: SME: Trying to authenticate with 00:12:43:8a:e5:21 (SSID='INFN-dot1x' freq=2447 MHz)
wlan0: Trying to associate with 00:12:43:8a:e5:21 (SSID='INFN-dot1x' freq=2447 MHz)
wlan0: Associated with 00:12:43:8a:e5:21
wlan0: CTRL-EVENT-EAP-STARTED EAP authentication started
wlan0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wlan0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21
wlan0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected
SSL: SSL3 alert: write (local SSL3 detected an error):fatal:protocol version
OpenSSL: openssl_handshake - SSL_connect error:0A000102:SSL routines::unsupported protocol
wlan0: CTRL-EVENT-EAP-FAILURE EAP authentication failed
wlan0: CTRL-EVENT-DISCONNECTED bssid=00:12:43:8a:e5:21 reason=23
wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="INFN-dot1x" auth_failures=1 duration=10 reason=AUTH_FAILED
wlan0: CTRL-EVENT-REGDOM-CHANGE init=CORE type=WORLD
```

I badly need a workaround since I use WPA Enterprise at work. Can anybody help with this?

@snack see the second page of the topic I linked to in the first reply to this issue. Please also consider reporting the issue upstream to the hostap project which also produces wpa_supplicant which does not seem to be aware of the issue.