On Sun, May 1, 2022 at 4:55 AM d. caratti <davide.caratti@xxxxxxxxx> wrote: > hi, > > Il giorno mer 6 apr 2022 alle ore 03:21 Masashi Honma <masashi.honma@xxxxxxxxx> ha scritto: > > > Thanks for the detailed log. > > > > But I could not find out the way to avoid this issue by fixing > > wpa_supplicant. > > > > According to the comment > > https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/comments/11, > > adding this to /usr/lib/ssl/openssl.cnf fixes the issue. > > > > [system_default_sect] > > Options = UnsafeLegacyRenegotiation > > > > Since this workaround exists, the OpenSSL developers have decided > > that this bug wont be fixed. > > according to James' analysis, it should be also possible to allow > unsafe legacy renegotiation only for wpa_supplicant, avoiding applying > this setting system-wide. That should be do-able with: > > SSL_CTX_set_options(ssl, SSL_OP_LEGACY_SERVER_CONNECT); Yes. Specifically: diff -up wpa_supplicant-2.10/src/crypto/tls_openssl.c.legacy-server-connect wpa_supplicant-2.10/src/crypto/tls_openssl.c --- wpa_supplicant-2.10/src/crypto/tls_openssl.c.legacy-server-connect 2022-01-16 15:51:29.000000000 -0500 +++ wpa_supplicant-2.10/src/crypto/tls_openssl.c 2022-04-28 02:47:26.863529683 -0400 @@ -1049,6 +1049,16 @@ void * tls_init(const struct tls_config SSL_CTX_set_options(ssl, SSL_OP_NO_SSLv2); SSL_CTX_set_options(ssl, SSL_OP_NO_SSLv3); + /* Many enterprise RADIUS server implementations (e.g. used in large + corporations and universities) do not support RFC5746 secure + renegotiation, and starting with OpenSSL 3.0, + SSL_OP_LEGACY_SERVER_CONNECT is no longer set as part of SSL_OP_ALL. + So until we implement a way to request SSL_OP_LEGACY_SERVER_CONNECT + only in EAP peer mode, just set SSL_OP_LEGACY_SERVER_CONNECT + globally. */ + + SSL_CTX_set_options(ssl, SSL_OP_LEGACY_SERVER_CONNECT); + SSL_CTX_set_mode(ssl, SSL_MODE_AUTO_RETRY); #ifdef SSL_MODE_NO_AUTO_CHAIN > as proposed at > https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c24. A more > complete fix would extend the wpa_supplicant configuration to permit > unsafe legacy TLS renegotiation only for users that explicitly require > it (so that it can be set only for connections that need this > setting). Long term, yes, it would be great to have this. Here is the problem: enterprise Wi-Fi vendors, who target large corporations and universities, ship embedded RADIUS server implementations in their Wi-Fi products. The TLS server implementation of these vendor RADIUS server implementations have largely escaped security scrutiny. The OpenSSL 3.0 change of no longer setting SSL_OP_LEGACY_SERVER_CONNECT as part of SSL_OP_ALL (which is set automatically for all TLS contexts) has exposed the fact that some of these vendors’ embedded RADIUS server implementations have, well, horrible TLS server implementations. RFC5746 secure renegotiation is literally 12 years old. If you operate a public web server that does not implement RFC5746 secure renegotiation, Qualys SSL Labs testing tool will give your web server an automatic “F” grade, because a web server that does not implement RFC5746 secure renegotiation is vulnerable to CVE-2009-3555. But all of this is hidden from end users, the people who connect to Wi-Fi networks. All end users see is that newer Linux distros are broken and cannot connect to Wi-Fi networks that worked just fine with previous distros. So they blame the distribution, or OpenSSL, or wpa_supplicant. Modifying wpa_supplicant to just always set SSL_OP_LEGACY_SERVER_CONNECT (that is, reverting to the pre-3.0 OpenSSL behavior) will avoid the connection failure. But this is fixing the symptom, not the problem. The problem is that there are enterprise Wi-Fi vendors in 2022 who think it’s acceptable to ship a RADIUS server implementation that doesn’t support TLS RFC5746 secure renegotiation. What would be ideal is if wpa_supplicant accepted a flag to indicate on a per-connection basis whether SSL_OP_LEGACY_SERVER_CONNECT should be set. If SSL_OP_LEGACY_SERVER_CONNECT was not requested, but the PEAP authentication fails because OpenSSL fails with error 0A000152 (SSL routines::unsafe legacy renegotiation disabled), then wpa_supplicant could return a specific “Wi-Fi network needs PEAP TLS unsafe legacy renegotiation” error message to the caller (typically NetworkManager on Linux systems), and the caller could then alert the user. E.g., NetworkManager could pop up this dialog box: This wireless network is insecure and does not support modern security standards. Please set the “permit insecure TLS renegotiation in PEAP authentication” option if you wish to connect to this Wi-Fi network. You may wish to ask the owner of this Wi-Fi network to correct the security issues with this Wi-Fi network. This would allow the user to easily work around the issue, while also making it clear that the problem is with the Wi-Fi network, not the user’s system. In turn, that will cause users to put pressure on the Wi-Fi operators to fix the security issues, which will cause the Wi-Fi operators to pressure their enterprise Wi-Fi vendors to implement RFC5746 in their RADIUS server implementations. But in the meantime, having wpa_supplicant unconditionally set SSL_OP_LEGACY_SERVER_CONNECT is the best option, as that is what the OpenSSL 3.0 migration guide recommends for TLS clients that need to connect to TLS servers that do not support RFC5746 secure renegotiation. _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
