Can't connec to PEAP anymore on current Ubuntu (2.10 built with openssl3)

[James Ralston]

On Sun, May 1, 2022 at 4:55 AM d. caratti <davide.caratti at gmail.com> wrote:

> hi,
>
> Il giorno mer 6 apr 2022 alle ore 03:21 Masashi Honma <masashi.honma at gmail.com> 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.