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

[Jouni Malinen]

On Sun, May 01, 2022 at 07:15:23PM -0400, James Ralston wrote:
> diff -up wpa_supplicant-2.10/src/crypto/tls_openssl.c.legacy-server-connect
> 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);

I'm a bit hesitant on doing this unconditionally. While this is clearly
the behavior with older OpenSSL versions, I do not really like the idea
of keeping this potential security vulnerability alive any longer. This
should not really have issues with EAP-TLS and maybe note with some of
the specific combinations of EAP-PEAP/TTLS and inner methods where the
TLS handshake and the inner method operations are bound together.
However, I'm not yet convinced that PEAPv0/v1 would be free of issues
(or EAP-TTLS with PAP/CHAP/EAP-GTC for that matter). While I cannot
really point to any specific RADIUS authentication server having an
implementation that would allow this type of an attack, I cannot really
rule out the possibility. I'd hope the old implementations that do not
support RFC5746 would not support TLS renegotiation at all, but it would
be difficult to sure about that without testing each such server
implementation individually.

One could obviously claim that it is not the duty of the EAP client to
enforce security in this front, but in practice, it seems to be much
more likely to get EAP clients upgraded than RADIUS servers in various
networks..

> > 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.

I'll probably add at least this into wpa_supplicant with a clear event
message identifying this specific issue to upper layers and a
network-specific configuration parameter for enabling the workaround
(and a suitable set of warnings to recommend against using this
workaround in cases where the user care about real security..).

> 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.

The wpa_supplicant changes for this should be straightforward, but this
would obviously depend on the additional UI components getting matching
functionality to be able to get this deployed for more common use cases
(i.e., for cases that do not expect the user to manually modify config
files based on debug log entries).

> 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.

I might be willing to do this as a build option (that is documented with
the warnings on the potential security issues in cases where the
authentication server has not been updated), but doing this as a
hardcoded, unconditional mechanism for over a decade old issue feels
wrong..

-- 
Jouni Malinen                                            PGP id EFC895FA