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 _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
