I too am having a problem connecting via wpa2 Enterprise (otherwise
wifi works normally). This is on a system that had been upgraded from
f35 to f36 on 2022-02-19 13:27. I encountered the wpa problem after a
2022-02-23 10:44 upgrade, and I recall that the wpa connection was working
fine before then on f36.

The relevant log entries are:

    Feb 23 10:58:47 dmk-laptop-21 wpa_supplicant[1404]: wlp147s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
    Feb 23 10:58:47 dmk-laptop-21 wpa_supplicant[1404]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
    Feb 23 10:58:47 dmk-laptop-21 wpa_supplicant[1404]: OpenSSL: openssl_handshake - SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled
    Feb 23 10:58:48 dmk-laptop-21 wpa_supplicant[1404]: wlp147s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

The same issue has been reported here:
https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-on-fedora-36/20288

does `update-crypto-policies --set legacy` and reboot make it work?

It seems it's related to disabled crypto (from openssl, used by wpa_supplicant).

Degrading the entire system to "legacy" however is not the right solution and I don't recommend that.
(I don't know what the right solution is).

(In reply to Thomas Haller from comment #2)
> does `update-crypto-policies --set legacy` and reboot make it work?
> 
> It seems it's related to disabled crypto (from openssl, used by
> wpa_supplicant).
> 
> Degrading the entire system to "legacy" however is not the right solution
> and I don't recommend that.
> (I don't know what the right solution is).

I'll give it a try.

If indeed the problem is due to my institution's AP using an unsafe protocol, the right solution is to prepare instructions for collecting information that can be used to file a ticket to those managing the wireless access point. I'd like to file a ticket with a subject line like: "Please upgrade AP software from Cisco version X to at least Y which includes encrypted handshaking. Currently my OS considers the AP too unsafe to connect." Is it possible to get such information?

Same problem with legacy settings after a reboot:

[root@dmk-laptop-21 koppel]# update-crypto-policies --show
LEGACY


Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: Associated with 00:42:68:62:55:6a
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-EAP-STARTED EAP authentication started
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
Apr 05 10:22:45 dmk-laptop-21 NetworkManager[1285]: <info>  [1649172165.4588] device (wlp147s0): supplicant interface state: associating -> associated
Apr 05 10:22:45 dmk-laptop-21 NetworkManager[1285]: <info>  [1649172165.4589] device (p2p-dev-wlp147s0): supplicant management interface state: associating -> associated
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=26 -> NAK
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=25
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:handshake failure
Apr 05 10:22:45 dmk-laptop-21 wpa_supplicant[1381]: OpenSSL: openssl_handshake - SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled
Apr 05 10:22:45 dmk-laptop-21 kernel: wlp147s0: Limiting TX power to 12 dBm as advertised by 00:42:68:62:55:6a
Apr 05 10:22:46 dmk-laptop-21 wpa_supplicant[1381]: wlp147s0: CTRL-EVENT-EAP-FAILURE EAP authentication failed

The legacy crypto policies didn't work for me either.

Is there a chance that this can be a blocker for F36 Final? This is going to break a lot of people's systems at work/school.

(In reply to Reese Armstrong (reesericci) from comment #6)
> Is there a chance that this can be a blocker for F36 Final? This is going to
> break a lot of people's systems at work/school.

OP, here's how to propose it:

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

This may be the relevant criterion, though it says nothing about specific methods of connecting to a network, not to mention, if a particular method is common enough to be considered a blocker:
https://fedoraproject.org/wiki/Basic_Release_Criteria#Remote_package_sources

OK, I just requested it in Bugzilla as a Final Blocker, we'll see if it gets some attention that way.

in any case, this does not seem to be a NetworkManager issue. Either wpa_supplicant or openssl. Reassigning.

as this rhbz links to the following question, did you try that suggestion? Did it work?
https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-on-fedora-36/20288/5

(In reply to Reese Armstrong (reesericci) from comment #6)
> Is there a chance that this can be a blocker for F36 Final? This is going to
> break a lot of people's systems at work/school.

It can't be a blocker because Silverblue is not a blocking deliverable:
https://docs.fedoraproject.org/en-US/releases/f36/blocking/

It can be a freeze exception, though. Changing the tags.

Actually, the Ask link in comment 1 talks about both Silverblue and Workstation. Putting the blocker nomination back.

(In reply to Thomas Haller from comment #10)
> as this rhbz links to the following question, did you try that suggestion?
> Did it work?
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-
> wifi-on-fedora-36/20288/5

I did take a look at the post, but haven't been able to try it yet. I'll try it when I get to school in an hour. Either way, I shouldn't have to do anything in order to get this to work, as I did in F35 (Workstation & Silverblue).

(In reply to Thomas Haller from comment #10)
> as this rhbz links to the following question, did you try that suggestion?
> Did it work?
> https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-
> wifi-on-fedora-36/20288/5

I can now connect (but I don't think the issue has been resolved). As suggested in that ask.fedoraproject.org post I edited /etc/pki/tls/openssl.cnf and I added the Options line so that the crypto_policy section appears as follows:

    [ crypto_policy ]

    Options = UnsafeLegacyRenegotiation
    .include = /etc/crypto-policies/back-ends/opensslcnf.config

That worked around the problem for me. That is, I can now connect. I would still like this written up somewhere, perhaps in release notes, so that those encountering the problem can verify that it's the handshake issue and to provide the kind of information needed to file a ticket. (See Comment 3).

Discussed during the 2022-04-11 blocker review meeting: [1]

The decision to classify this bug as an RejectedBlocker was made:

"This is a feature of openssl and not a bug. We will mark it in commonbugs for reference."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt

Excuse me, what? Not being able to connect to WPA2 Enterprise networks is a feature? That is ridiculous.

Discussed during the 2022-04-11 blocker review meeting: [1]

The decision to classify this bug as an RejectedFreezeException was made:

"The bug in question is actually expected behavior in openssl. We reject it as an FE on this basis."

[1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2022-04-11/f36-blocker-review.2022-04-11-16.00.log.txt

So what should be done about this? The UX is terrible right now, and how do we convey this to the end user? Putting it in release notes and calling it a day is not a solution to the issue at hand.

Putting it in the release notes would probably be the best way if the "fix" isn't going to be added to a package update.

"Excuse me, what? Not being able to connect to WPA2 Enterprise networks is a feature? That is ridiculous."

No, that's not an accurate description of the issue AFAIK. The problem will happen only with networks that do not support secure renegotiation. This is to do with the design or configuration of the router (or whatever is handling the other end of the connection). See the "SECURE RENEGOTIATION" section of https://www.openssl.org/docs/man3.0/man3/SSL_clear_options.html for more details.

I agree that the user not getting an explanation of why this failed is a problem; retitling the bug to reflect that. wpa_supplicant clearly *does* report the problem, but something further up the chain swallows it. Moving to NetworkManager for now at least - I'm not clear whether NetworkManager is not reporting the error to GNOME, or GNOME is getting some indication of the error from NM but not passing it on to the user.

That changes things. Thanks for clearing that up! I will file a complaint with my network admin about this.

--reese

(In reply to Adam Williamson from comment #20)
> "Excuse me, what? Not being able to connect to WPA2 Enterprise networks is a
> feature? That is ridiculous."
> 
> No, that's not an accurate description of the issue AFAIK.

I respectfully disagree. This *specific use case* is a bug, not a feature, and this should absolutely be a blocker for F36:

1. The real-world security implications of permitting insecure renegotiation during the PEAP TLS session are negligible. There is zero risk to the client; an MitM attacker cannot obtain user credentials or fake the authentication.

2. We also encountered this at our organization, with RHEL9 beta. Despite running a modern Wi-Fi infrastructure with modern Wi-Fi equipment, our network team reports that the Wi-Fi equipment provides no mechanism to enable RFC5746 secure renegotiation on the EAP server. This is likely because until OpenSSL 3.0, literally *nothing* cared about whether any EAP server anywhere supported RFC5746. Wi-Fi hardware vendors simply *do not care* about this. As such, getting RFC5746 support will not be a quick fix; this will take literally years/decades.

3. Working around this is horrendous: it requires modifying the wpa_supplicant systemd unit file to point to a different openssl.cnf file, then manually creating that openssl.cnf file and adding the “UnsafeLegacyRenegotiation” configuration option. See: https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/comments/22

Fedora 36 *must* ship with the work-around (point #3 above) enabled by default.

Long-term, there needs to be an option in the “Wi-Fi Security” tab in the NetworkManager configuration to enable unsafe TLS renegotiation during PEAP authentication, and both NetworkManager and wpa_supplicant must coordinate to ensure that the user understands what is happening (and how to resolve it) when PEAP authentication fails because the PEAP server does not support RFC5746. For more information, see: https://bugzilla.redhat.com/show_bug.cgi?id=2077973#c6

A downstream bug in Fedora does not seem like the place to debate upstream openssl security policy choices, to me.

Your description of the workaround as "horrendous" does not seem accurate at least on Fedora, per comment #14 just editing a single file is sufficient.

Ok, I’ve dug into this some more.

First: the UnsafeLegacyRenegotiation option (corresponding to SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION) is the wrong option. That will enable unsafe legacy renegotiation in *both* client and server contexts. That’s bad. The correct option to use here is UnsafeLegacyServerConnect (corresponding to SSL_OP_LEGACY_SERVER_CONNECT), which allows only TLS clients to connect to TLS servers that permit unsafe legacy renegotiation, while still causing server instances to reject a TLS client that does not support RFC5746 secure renegotiation.

(In reply to Adam Williamson from comment #23)
> A downstream bug in Fedora does not seem like the place to debate upstream
> openssl security policy choices, to me.

I respectfully disagree.

Quoting the migration guide <https://www.openssl.org/docs/man3.0/man7/migration_guide.html#TLS-Changes>:

> Secure renegotiation is now required by default for TLS connections
> 
> Support for RFC 5746 secure renegotiation is now required by default
> for SSL or TLS connections to succeed. Applications that require the
> ability to connect to legacy peers will need to explicitly set
> SSL_OP_LEGACY_SERVER_CONNECT. Accordingly,
> SSL_OP_LEGACY_SERVER_CONNECT is no longer set as part of SSL_OP_ALL.

There have been independent reports of Wi-Fi PEAP breakage for Fedora 36 beta, RHEL9 beta, and other Linux distributions that have started shipping OpenSSL 3.0. This is a strong indication that lack of RFC5746 support in enterprise vendor Wi-Fi hardware is a widespread issue.

Thus, wpa_supplicant is an application that requires the ability to connect to legacy TLS servers, and per the OpenSSL migration, it is not just appropriate but necessary for wpa_supplicant to set the SSL_OP_LEGACY_SERVER_CONNECT option.

wpa_supplicant’s failure to set SSL_OP_LEGACY_SERVER_CONNECT is a bug. It is a bug that predates OpenSSL 3.0, but was occulted because before OpenSSL 3.0, SSL_OP_ALL included SSL_OP_LEGACY_SERVER_CONNECT and thus masked the bug. So it’s perfectly understandable why this bug was not caught until now. But it is a bug nonetheless.

> Your description of the workaround as "horrendous" does not seem accurate at
> least on Fedora, per comment #14 just editing a single file is sufficient.

Again, I respectfully disagree.

First: the edit suggested in comment #14 is not just completely inappropriate but *dangerous*: setting “Options = UnsafeLegacyRenegotiation” in the default (system-wide) openssl.cnf file will permit unsafe renegotiations, for *all* applications linked against OpenSSL, in *both* client and server contexts. *THIS WILL EFFECTIVELY RE-ENABLE CVE-2009-3555 SYSTEM-WIDE*. I know David (the comment author) didn’t intend that comment to be bad advice, and I’m not trying to throw him under the bus here, but bad advice it certainly is.

Even the safer “Options = UnsafeLegacyServerConnect” (which permits only TLS clients to connect to TLS servers that don’t support RFC5746, while still defaulting TLS servers to require clients to support RFC5746) should not be placed in the system-wide openssl.cnf file, as that re-enables CVE-2009-3555 for all OpenSSL TLS clients on the system. This effectively defeats the security policy choice made in OpenSSL 3.0 to no longer set SSL_OP_LEGACY_SERVER_CONNECT as part of SSL_OP_ALL (because enough TLS server implementations now support RFC5746 that it is appropriate to place to onus of setting SSL_OP_LEGACY_SERVER_CONNECT onto the individual applications that must communication with legacy servers and thus specifically require it).

To properly work around this wpa_supplicant bug without re-enabling CVE-2009-3555 system-wide, the user must do the following:

$ cat 1>>/etc/sysconfig/wpa_supplicant <<EOF

# See /etc/wpa_supplicant/openssl.cnf for the explanation why using a custom
# openssl.cnf file for wpa_supplicant (which is what setting OPENSSL_CONF here
# does) is necessary.

OPENSSL_CONF="/etc/wpa_supplicant/openssl.cnf"
EOF
$ cp -p /etc/pki/tls/openssl.cnf /etc/wpa_supplicant/openssl.cnf
$ cd /etc/wpa_supplicant
$ patch -p0 <<EOF
--- openssl.cnf.old	2022-03-18 12:49:28.000000000 -0400
+++ openssl.cnf	2022-04-28 01:08:10.260379609 -0400
@@ -36,6 +36,24 @@
 
 [ crypto_policy ]
 
+# Starting with OpenSSL 3.0, OpenSSL no longer includes
+# SSL_OP_LEGACY_SERVER_CONNECT in SSL_OP_ALL, as most TLS servers now support
+# RFC5746 TLS secure renegotiation.  TLS client applications that specifically
+# need to connect to TLS servers that do not support RFC5746 TLS secure
+# renegotiation should (and must) explicitly set SSL_OP_LEGACY_SERVER_CONNECT.
+#
+# Wi-Fi PEAP authentication uses TLS, and a nontrivial number of enterprise
+# Wi-Fi implementations that perform PEAP authentication fail to implement
+# RFC5746 TLS secure renegotiation.  But wpa_supplicant does not set
+# SSL_OP_LEGACY_SERVER_CONNECT when it performs client PEAP authentication,
+# because the pre-3.0 OpenSSL behavior of including
+# SSL_OP_LEGACY_SERVER_CONNECT in SSL_OP_ALL occulted the need to do so.
+#
+# Until wpa_supplicant properly sets the SSL_OP_LEGACY_SERVER_CONNECT option,
+# we must do so manually.
+
+Options = UnsafeLegacyServerConnect
+
 .include = /etc/crypto-policies/back-ends/opensslcnf.config
 
 [ new_oids ]

EOF
$ restorecon -F /etc/wpa_supplicant/openssl.cnf
$ systemctl try-restart wpa_supplicant

I stand by my “horrendous” comment. It is completely unacceptable to expect a *user* to do this to work around what is fundamentally a bug with wpa_supplicant.

Moreover, once the user forks a custom openssl.cnf file for wpa_supplicant, it’s going to persist forever, across Fedora upgrades, until the user does a clean install, because /etc/sysconfig/wpa_supplicant is flagged as config(noreplace) in the wpa_supplicant rpm package.

But it’s even worse: how is the user supposed to figure out that this is even necessary to do in the first place?

When the wpa_supplicant bug occurs, NetworkManager behaves exactly as if the user entered an incorrect password. The only clue what is really happening (and where the true problem lies) is the cryptic “SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled” message that is logged to the system log—which only system administrators can see. From there, it’s off to web searches to try to find what that error means and how to resolve / work around the problem.

If the user is lucky, they’ll stumble across an explanation of how to work around the bug in wpa_supplicant without re-enabling CVE-2009-3555 system-wide (a la comment #14). If the user is unlucky, they’ll render their entire system, including OpenSSL TLS servers, vulnerable to CVE-2009-3555.

The decision to reject this bug as a blocker bug for Fedora 36 was made without a complete understanding of precisely what the bug is. Breaking the ability to connect to PEAP Wi-Fi networks is *NOT* a feature of OpenSSL 3.0, as the OpenSSL 3.0 migration guide is painfully explicit that it is the responsibility of applications that need to connect to legacy TLS servers to set SSL_OP_LEGACY_SERVER_CONNECT. Rather, this is a long-standing bug with wpa_supplicant (assuming SSL_OP_LEGACY_SERVER_CONNECT will be set automatically, instead of manually setting it) that OpenSSL 3.0 simply exposed.

Looking at the wpa_supplicant source code, I strongly suspect this one-line patch will have the same effect as setting “Options = UnsafeLegacyServerConnect” in openssl.cnf:

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

(WARNING: I have not tested this yet. This is a 1-in-the-morning patch attempt based on a 5-minute perusal of the source code. Please test before using!)

As per my comments on BZ#2077973, long-term, this should be addressed by adding a “permit unsafe legacy TLS renegotiation in PEAP authentication” option to both NetworkManager and wpa_supplicant, with an intelligent error message along the lines of “this Wi-Fi network requires the ‘permit unsafe legacy TLS renegotiation in PEAP authentication’ option to be enabled” communicated back to the user. But until that can be implemented, the simplest way to squash the bug is for wpa_supplicant to unconditionally set SSL_OP_LEGACY_SERVER_CONNECT.

It is not clear to me how to appeal the rejection of a blocker bug nomination, but an appeal is clearly needed here.

Resetting blocker decision back to nominated as requested in comment 24.

Comment 24 seems accurate to me. Thanks James for the effort!

The proper solution is mostly in NetworkManager, to improve error reporting and allow to opt-in for unsafe behavior on a per-profile basis. That will be a lot of upstream work (patch welcome).

The workaround in supplicant seems reasonably simple and what we should do for now. I think that supplicant should by default use a different openssl.cnf, which is shipped and maintained by Fedora's supplicant package. That allows the expert user to still modify it, and by default we'd ship a less strict SSL configuration (for now). After all, different users of openssl have different requirements w.r.t. security.

I'd reassign this bug to wpa_supplicant.

Thanks for the valuable added details, James, you're right that I (and probably others who voted) was not aware of all of those. This will be discussed again at the go/no-go meeting happening in just over an hour in #fedora-meeting on libera.chat or chat.fedoraproject.org , if you want to join in.

Unfortunately we now have to either delay the release again to fix this, or waive it; if your clarification had been available a few days earlier we could've got a fix in :|

tested this with RC1.2 andit connects to the my Uni Network using PEAP and MSChapv2 with no CA Certificate

In today's Go/No-Go meeting, we accepted this as a blocker as this bug is a conditional violation of all criteria that imply network access and any 'install must work' criteria in cases where an affected WiFi network is used.
https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no_go-meeting.2022-04-28-17.01.log.html#l-258

(In reply to Adam Williamson from comment #27)
> Unfortunately we now have to either delay the release again to fix this, or
> waive it; if your clarification had been available a few days earlier we
> could've got a fix in :|

Alas, it took me a little bit to fully wrap my head around what was happening here: I couldn’t understand why SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION was just cropping up now, as OpenSSL disabled unsafe legacy renegotiation (and added that option to prevent it) way back in 1.1.0. Literally nothing about SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION changed in 3.0.

But that was a red herring. What changed in 3.0 was the removal of SSL_OP_LEGACY_SERVER_CONNECT from SSL_OP_ALL. That’s what finally exposed the wpa_supplicant bug.

(In reply to Ben Williams from comment #28)
> tested this with RC1.2 andit connects to the my Uni Network using PEAP and
> MSChapv2 with no CA Certificate

Do you mean you tested with the patch to wpa_supplicant I proposed in comment #24, or you are using an unpatched wpa_supplicant and are unaffected by the bug?

BTW, our network group shared the vendor’s response to their (upstream) ticket with me. The vendor admits their Wi-Fi EAP implementation does not support RFC5746 secure renegotiation. They’ve added it as a feature request for subsequent releases, but feature requests are prioritized based on how many customers request the feature.

(In reply to Thomas Haller from comment #26)
> The proper solution is mostly in NetworkManager, to improve error reporting
> and allow to opt-in for unsafe behavior on a per-profile basis. That will be
> a lot of upstream work (patch welcome).

It’s not just NetworkManager, though. Ideally, wpa_supplicant needs to provide an option so that NetworkManager can ask wpa_supplicant to set SSL_OP_LEGACY_SERVER_CONNECT on a per-connection basis. And if PEAP authentication fails because SSL_OP_LEGACY_SERVER_CONNECT was needed (but not enabled), wpa_supplicant needs to communicate that specific failure case back to NetworkManager, so that NetworkManager can explain (via a dialog pop-up) to the user what the issue is and how to work around it.

If done correctly, this will enlist Linux users to ask the owners of the non-RFC5746-compliant Wi-Fi systems why Linux is muttering about their Wi-Fi being unsafe… which will encourage those owners to submit feature requests to their vendors to support RFC5746.

And let’s be honest: the reason why Wi-Fi vendor’s TLS server implementations have escaped security scrutiny all these years is because they are essentially embedded implementations that are not public. (I will admit that before I encountered this issue, I was unaware that PEAP authentication used TLS under the hood.) So the Eye of Sauron that is https://www.ssllabs.com/ssltest/ (for which failure to support RFC5746 is an automatic “F” grade) has never been able to find them. A little public sham^H^H^H^H^H^H^H^H^H^H^H sunlight will go far here.

(RFC5746 was published in February 2010, ffs. If large Wi-Fi vendors couldn’t even be bothered to implement that, more than a decade later, what other security issues exist in their TLS implementations?)

So, now this has been accepted as a blocker, we need a build of wpa_supplicant with the workaround in place. Thomas, can you do that? If not, who should we ask? I'm a proven packager so I have the power to do it, but I'm not sure I have a strong enough grasp on all the details here to be sure I'm doing the right thing.

I'm very excited to hear that a fix is in the works! Hopefully this doesn't delay the release of F36 too much though...


--reese

(In reply to Adam Williamson from comment #31)
> So, now this has been accepted as a blocker, we need a build of
> wpa_supplicant with the workaround in place. Thomas, can you do that? If
> not, who should we ask? I'm a proven packager so I have the power to do it,
> but I'm not sure I have a strong enough grasp on all the details here to be
> sure I'm doing the right thing.

givent that the workaround is patch at comment #24, I can manage to do a wpa_supplicant build. Should we try submitting officially the patch to hostapd mailing list, or keep it as non-upstream?

Well, the author of comment #24 wrote "(WARNING: I have not tested this yet. This is a 1-in-the-morning patch attempt based on a 5-minute perusal of the source code. Please test before using!)", so rather than just slap it in I was hoping we could have a subject matter expert check it over...

I'm not sure whether it's upstream appropriate, that's another thing someone more experienced in the area could say. But for Fedora release timeframe purposes, we can't really wait for upstream approval *before* fixing it downstream, we need to do a downstream build ASAP whether or not we submit it upstream at the same time.

Thanks!

(In reply to Adam Williamson from comment #34)
> Well, the author of comment #24 wrote "(WARNING: I have not tested this yet.
> This is a 1-in-the-morning patch attempt based on a 5-minute perusal of the
> source code. Please test before using!)", so rather than just slap it in I
> was hoping we could have a subject matter expert check it over...

... understood. Just in case, there's a koji scratch-build at [1], built from the source in [2] that includes the patch at comment #24.
 
> I'm not sure whether it's upstream appropriate, that's another thing someone
> more experienced in the area could say.

maybe we can share what we have as a reply to the thread [3] in the official hostap ML?
thanks!

-- 
davide

[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=86457235
[2] https://src.fedoraproject.org/fork/dcaratti/rpms/wpa_supplicant/tree/bz2072070
[3] http://lists.infradead.org/pipermail/hostap/2022-April/040353.html

Just for clarification, can we name and shame the vendors who don't support secure renegotiation?

https://www.openssl.org/docs/man1.0.2/man3/SSL_get_secure_renegotiation_support.html says:

"OpenSSL 0.9.8m and later always attempts to use secure renegotiation as described in RFC5746."

There is literally nothing that the RADIUS server has to do in order to support this.  OpenSSl 0.9.8m was released in 2010.  There's no excuse for vendors to continue shipping such old software.

Also a minor nit:  It's not the " Wi-Fi vendor’s TLS server implementation", or the "EAP server".  It's the RADIUS server.  Many vendors have embedded RADIUS servers.  But I'm not aware of any EAP server which is *just* a RADIUS server.  All EAP servers are implemented 1-1 with RADIUS servers.

I tried the build of wpa_supplicant from Comment 35 (using the link below), and I'm able to connect. I had been experiencing the insecure handshake issue, and had applied several diagnostic configuration changes, some of which worked. I removed all of those diagnostic configuration changes and installed the new wpa_supplicant, and I can now connect.


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=86457235

Thanks, David. As we're getting short on time again, if nobody who's an expert in the area chimes in soon, I'll review the patch myself as best I can and do a build today.

FEDORA-2022-0c9603c2da has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c9603c2da

*** Bug 2076754 has been marked as a duplicate of this bug. ***

FEDORA-2022-0c9603c2da has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-0c9603c2da`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-0c9603c2da

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I’m seeing this problem with RHEL9 beta, not Fedora 36 beta, so I can’t easily test the Fedora wpa_supplicant update, but for RHEL9 beta I rebuilt wpa_supplicant using the srpm package with the patch above attached, and now I can connect to our organization’s Wi-Fi network with RHEL9 beta, when before it failed. So I’m fairly confident the patch restores the ability to connect to Wi-Fi networks that use bad RADIUS server implementations that don’t implement RFC5746 secure renegotiation, which is the goal.

(In reply to Davide Caratti from comment #35)
> maybe we can share what we have as a reply to the thread [3] in the official
> hostap ML?

I did, here:

http://lists.infradead.org/pipermail/hostap/2022-May/040511.html

I will wait a few days, then poke upstream again.

(In reply to aland from comment #36)
> Just for clarification, can we name and shame the vendors who don't support
> secure renegotiation?

Our organization uses Arubet Networks for our enterprise Wi-Fi deployment, so other Aruba sites will likely hit this.

(In reply to aland from comment #36)
> Also a minor nit:  It's not the " Wi-Fi vendor’s TLS server implementation",
> or the "EAP server".  It's the RADIUS server.  Many vendors have embedded
> RADIUS servers.  But I'm not aware of any EAP server which is *just* a
> RADIUS server.  All EAP servers are implemented 1-1 with RADIUS servers.

Yes, thanks for the correction; I was not using good terminology.

Can confirm about Aruba. My school uses Aruba and that’s  where I saw the issue first crop up.

—reese

I just tested this using a Fedora 36 Beta Laptop.  On initial boot the unit failed to connect to the wireless network.  Attempted several times, essentially a silent failure.  Updated wpa-supplicant to the patched version, rebooted and successfully connected.  I am on Arubet Networks.

Thanks, Neil.

FEDORA-2022-0c9603c2da has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.

Confirmed that this works fine on our office network (using Aruba)

wpa_supplicant has now fixed this upstream, by adding an option to request SSL_OP_LEGACY_SERVER_CONNECT: 

https://lists.infradead.org/pipermail/hostap/2022-May/040522.html
https://w1.fi/cgit/hostap/commit/?id=566ce69a8d0e64093309cbde80235aa522fbf84e
https://w1.fi/cgit/hostap/commit/?id=a561d12d24c2c8bb0f825d4a3a55a5e47e845853

I think the option is global, so it can be used either for all networks:

phase1="allow_unsafe_renegotiation=1"

Or for a specific network:

network={
        ssid="dammit-Aruba"
        phase1="allow_unsafe_renegotiation=1"
}

Additionally, with these patches, wpa_supplicant now detects when PEAP fails because OpenSSL throws SSL_R_UNSAFE_LEGACY_RENEGOTIATION_DISABLED, and propagates that error. So it is now possible for NetworkManager to not only have a configuration option to enable phase1="allow_unsafe_renegotiation=1" on a per-interface basis, but to detect when a wireless network needs phase1="allow_unsafe_renegotiation=1" but it wasn’t supplied (e.g., because NetworkManager defaults to leaving it off, and the user didn’t check the appropriate checkbox in nm-connection-editor.

For now, probably the best thing to do is to ship Fedora 36 with the patched wpa_supplicant that unconditionally sets SSL_OP_LEGACY_SERVER_CONNECT. Once NetworkManager is updated to implement allowing the user to select phase1="allow_unsafe_renegotiation=1" on a per-network basis, then the patch can be dropped, and we will be where we want to be: if a user attempts to connect to a WiFi network whose RADIUS server doesn’t support RFC5746 secure renegotiation, they will be informed exactly why the connection failed, and how they can work around it. And as the operators of the WiFi networks get called out for failing to support RFC5746 secure renegotiation, they are going to turn around and complain to their vendors… and thus vendors that support neither TLSv1.3 or RFC5746 secure renegotiation are going to be shamed.

(Renegotiation was one of the many protocol features that TLSv1.3 deliberately dropped because it was more of a headache / security deficiency than it was useful. So if both wpa_supplicant and the RADIUS server support TLSv1.3, RFC5746 secure renegotiation is irrelevant.)

Maybe this will be ready in time for Fedora 37?

BTW, I was remiss in pointing out: I approached wpa_supplicant upstream over this issue, and Jouni Malinen was fantastic in addressing it. I didn’t expect any movement on this for potentially months; he added the phase1="allow_unsafe_renegotiation=1" feature 6 days after I explained the issue on the hostap mailing list. Boom!

Thomas Haller, I have not delved into the NetworkManager source code, so alas, I am unable to assist with a patch. But since my organization uses Aruba, and I experience the problem, I will happily assist in testing once this feature lands in NetworkManager upstream.

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1218 would make this opt-in in NetworkManager.

To detect the condition and do something about it is TODO (and much more work).
I think the only thing that NetworkManager should do when it detects the issue, is to make it clear to the user. So failing to do that, is bad UX/discoverability (and serious), but there is no other functional change. The problem for NetworkManager is that it has no good mechanism for sending informational messages to the NM clients. That needs improvements, but is a larger effort.

Good this this issue is being cared about. But that's only working around vendors that don't keep up with crypto, and the real fix should be to chase them. Knowing some Aruba people, I'd like to request some intel from the commenters above: in which releases did you encounter unsafe renegotiations being needed by the server side? Is this really happening on current releases or only old ones nearing EOL?

(In reply to Stefan from comment #51)
> Good this this issue is being cared about. But that's only working around
> vendors that don't keep up with crypto, and the real fix should be to chase
> them. Knowing some Aruba people, I'd like to request some intel from the
> commenters above: in which releases did you encounter unsafe renegotiations
> being needed by the server side? Is this really happening on current
> releases or only old ones nearing EOL?

As of 2022-04-28, Aruba asserted in response to our support ticket:

> From case description I could see that you'd like to have support for RFC5746 to make new linux devices work with PEAP against CPPM server.
> 
> Presently there's no SW version of CPPM that supports RFC5746.
>
> Our Developers are already aware of it – however, didn't add it as of yet.
>
> It's marked as a new feature request with reference ID: CP-19665.
>
> A new feature is always routed through sales/systems engineers from customers and through SEs to our PLM for adding the support of it.
>
> As this isn't a supported feature not a bug, its beyond TAC's limitations.
>
> Feel free to forward this email to your Aruba accounts team and suggest them to reach out to Aruba Clearpass PLM – referencing the above ID.
>
> You add up the need for it with your description as well.

I've said this elsewhere, so I'll say it here again.

The Aruba product is based on FreeRADIUS 1.1.4, from 2007.  I have some of their code (GPL FTW), and can say this with 100% authority.  I suspect that the OpenSSL version they're using is about the same vintage.

The Aruba ClearPass engineering team is tiny.  Last I checked, about 2 people.  So it's safe to say that upgrading their product will be difficult.

To make matters worse, TLS 1.3 is coming.  RFC 9190 standardizes EAP-TLS using TLS 1.3.  Updates to PEAP / TTLS / etc. are coming next.  Supplicants are upgrading.  Servers are upgrading.

If Aruba is having a hard time implementing a 12 year-old RFC, then TLS 1.3 will be significantly more difficult for them.  At which point their product will become much less useful.

Well if they keep building on a GPL product, they are producing derivatives of that. The GPL license then requires them to make the source code available on an ongoing basis.

So, if it indeed (still) is based on FreeRADIUS, we wouldn't need to guess what their software does. We could simply ask for a copy of the source code and take a look.

Otherwise, if they have revamped their product entirely, with fresh code, not including a single line of FreeRADIUS source, then a) we couldn't take a look but b) it would be an entirely different product altogether, so any worries about stale code from decades ago would be moot.

From my understanding of Alan's comment, he has GPL code from the *current* version? Care to share?

The last source I have is from 2008 or so.  I've had conversations with Aruba since then, but I don't have a more recent version of the source.

I doubt very much it's changed significantly since then.

Just FYI, today our network team informed me:

> I just confirmed with Aruba that RFC5746 has been added to the recently released code. I’ll get this code running in our lab to see what all is required to enable it and then we’ll schedule when we can push this out to production.

So while it looks like upstream Wi-Fi vendors are finally beginning to feel the heat and take action, it will likely take years until a majority of sites are updated…

I think we hit very close to the right solution here, but I fear the changes in wpa_supplicant and NetworkManager are probably not quite right. We may have all been confused/misled by two subtle points.

First: does the RADIUS server actually perform a rehandshake? Is a rehandshake required by the PEAP protocol, or something the server does just for fun? I would guess that it is probably not rehandshaking at all! Rather, I think OpenSSL drops the connection on the initial handshake when it sees that the server does not support the RFC 5746 secure rehandshake extension. Looking at the error messages pasted above, and looking at the change in wpa_supplicant, and looking at the OpenSSL source code ssl/statem/extensions.c in the final_renegotiate() function, I strongly suspect OpenSSL is blocking the *initial* handshake, not a rehandshake. Thing is, blocking servers that do not support RFC 5746 on the initial handshake is quite strict. Eventually we will surely want to do so, but for now, the existence of this bug report is enough to indicate it's too soon. The RFC 5746 TLS extension is just a way for the server to tell the client "I can rehandshake securely." If the server does not actually attempt to rehandshake, then lacking RFC 5746 is not actually a security risk. I'm not certain whether it's reasonable for OpenSSL to start blocking such servers by default, because it should be perfectly acceptable for servers to refuse to rehandshake altogether rather than implement RFC 5746, but perhaps OpenSSL is using this as a clue that the server is older and likely vulnerable to other unrelated issues. Anyway, I think it's totally fine for NetworkManager and wpa_supplicant to support connecting to servers that do not support secure rehandshakes, even by default. To be clear: connecting to a server that does not support secure renegotiation is not a security risk as long as the client refuses to renegotiate, and OpenSSL will definitely refuse. (Note "rehandshake" == "renegotiate," exact same thing, used interchangeably.)

In contrast, actually allowing rehandshakes with servers that do not support secure rehandshakes would be risky and unusual. That should not be needed in 2022. Hardware that wasn't updated for this a decade ago should have been shredded *long* ago. The seriousness of allowing an insecure rehandshake depends on the specifics of how the higher-layer protocol (PEAP) operates, but suffice to say most of TLS security guarantees are thrown out, and it should not be permitted without *very* serious consideration. I would want to see an explanation for why the security impact statements in comment #22 are really true. But again, I do not think that is actually happening here, because I don't think the server is actually rehandshaking, so it probably doesn't matter.

Second: I fear the new wpa_supplicant and NetworkManager options are likely misnamed. The wpa_supplicant option is named "allow_unsafe_renegotiation", but in fact it only toggles SSL_OP_LEGACY_SERVER_CONNECT, not SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION. I think SSL_OP_LEGACY_SERVER_CONNECT allows an initial handshake with servers that do not support secure renegotiation, while SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION additionally allows rehandshakes. I would expect an option named "allow_unsafe_renegotiation" to toggle SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION instead. But please don't add such an option, because we known it's not needed, because this bug was resolved without it. Instead, just rename the existing option to reflect what it's actually doing, e.g. "allow_legacy_servers".

Looking at the OpenSSL documentation https://wiki.openssl.org/index.php/List_of_SSL_OP_Flags, I think the documentation of SSL_OP_LEGACY_SERVER_CONNECT is wrong, which probably did not help. It says "Allow legacy insecure renegotiation between OpenSSL and unpatched servers only," but that is suspicious because it does not match the name of the flag. Looking at OpenSSL's final_renegotiate() function in extensions.c, which is called during every handshake to indicate whether or not the secure rehandshake extension is set, it looks the real behavior matches the name of the flag, not its documentation; i.e. it looks like that flag only permits connecting to the server, but an actual insecure rehandshake would still be blocked. If that is correct, then the new wpa_supplicant and NetworkManager options are both misnamed and should be renamed. (This is certainly not the first time incorrect OpenSSL docs led developers badly astray.)

If I'm correct about the stuff above, then after renaming both the wpa_supplicant and NetworkManager options, we should consider enabling them by default, instead of as a fallback. As long as the options exist, users will try to use them if needed, so having them off by default is arguably more a confusing annoyance than a useful security improvement. (But of course, please do not actually enable insecure rehandshakes, which are not OK.)

Disclaimer: all I've done here is skim Bugzilla comments and glance at source code. Haven't tested any of this. Could be wrong.

It's not quite like that, unfortunately. 

The attack with renegotiations works as described in RFC5746 "Introduction": the attacker is the FIRST one who talks to the server (initial negotiation), then does $evilthings in the ongoing conversation, and then tells the server to "re"negotiate with the actual client. The client does not know anything about the preceding interactions, so for the client it's a first negotiation. So the legitimate client can prohibit (further) renegotiations as much as it likes; the damage is already done.

I am still not saying there is an /actual/ threat in that in the particular context of EAP authentication; maybe this initial contact with an attacker can do actual harm here, or maybe not. But at least by general principle, your argument that the legitimate client can prevent harm by not renegotiating does not appear to be valid.

So there mere fact that a server supports insecure renegotiations is enough to distrust any conversation a legitimate client could have with the server, and the flag that allows the client to connect anyway does open up the renegotiation loophole.

OK, wow, I see you are correct! Thanks for commenting to dispel my bogus assumption. (Fortunately, it seems I've lucked out and amazingly not messed up any GTlsConnection APIs due to this mistake.)

Looking at https://www.gnutls.org/manual/gnutls.html#Safe-renegotiation, I see GnuTLS intentionally decided to secure servers always, but leave clients vulnerable if connecting to legacy servers. That matches OpenSSL's longstanding behavior. It seems reasonable for OpenSSL to become stricter now, and also reasonable for wpa_supplicant and NetworkManager to optionally permit reverting that choice. So... we're good.

Well, mostly. I would still recommend renaming the new wpa_supplicant and NetworkManager flags to match the underlying OpenSSL flag that they are using, to avoid future semantic mismatch. It seems likely that SSL_OP_LEGACY_SERVER_CONNECT will affect other stuff in the future.

I think we’re over-thinking this.

There are three key considerations here:

1. Exploiting insecure TLS renegotiation requires the attacker to be able to perform a man-in-the-middle attack.

2. Even if an attacker successfully performs a TLS renegotiation attack against an insecure server, the attacker never sees the traffic between the client and the victim server.

3. As a consequence of #2, insecure TLS renegotiation is solely a *server* vulnerability. A TLS client that does not support RFC5746 can help enable the attack, but is not vulnerable to it.

Consideration #3 is why OpenSSL waited a whopping 12 years from when they first implemented RFC5746 (and defaulted TLS servers to refuse renegotiation attempts from clients that didn’t indicate support for RFC5746 during the initial handshake) to when they changed the default TLS client behavior to refuse to connect to TLS servers that don’t support RFC5746. TLS servers were vulnerable, and had to be fixed immediately. TLS client weren’t: at worst, they could only help enable attacks against vulnerable servers. And bluntly, that’s the server owner’s own damn fault.

In the context of EAP authentication, whether the RADIUS server supports RFC5746 is of near-zero concern to the wireless client:

1. To perform a TLS insecure renegotiation attack, the attacker must perform a near-perfect man-in-the-middle attack between the wireless client and the RADIUS server over a broadcast medium. Good luck with that. (OK, yeah, for 801.1X this might be more feasible. But that’s not where this problem surfaced.)

2. Even if the attacker somehow miraculously manages to succeed, he will be unable to access whatever credentials were transmitted by the wireless client. At best, he might be able to piggyback on those credentials to get onto the network… but if he could man-in-the-middle the traffic, in a significant sense he’s already on the network, yes?

If NetworkManager and wpa_supplicant can help smoke out RADIUS servers that don’t implement RFC5746, then great, but end users shouldn’t be inconvenienced in any way to do it. Because they don’t care if the RADIUS server is an ancient pile of crap; it doesn’t affect them.

(In reply to Michael Catanzaro from comment #59)
> Well, mostly. I would still recommend renaming the new wpa_supplicant and
> NetworkManager flags to match the underlying OpenSSL flag that they are
> using, to avoid future semantic mismatch. It seems likely that
> SSL_OP_LEGACY_SERVER_CONNECT will affect other stuff in the future.

While I agree that it’s confusing that the new wpa_supplicant "allow_unsafe_renegotiation" flag is toggling the OpenSSL SSL_OP_LEGACY_SERVER_CONNECT option instead of the OpenSSL SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION option:

1. End users don’t care (and arguably, shouldn’t have to care, as NetworkManager should work with wpa_supplicant to automatically enable "allow_unsafe_renegotiation" if it is required).

2. The wpa_supplicant flag name matches the “unsafe legacy renegotiation disabled” OpenSSL error message, which is useful until #1 is achieved and affected users have to figure out what option to set.

But most importantly:

3. The "allow_unsafe_renegotiation" name was picked by upstream (see my comment #48), and it would be even more confusing if Fedora were to name it differently than other distros. If you want to change the name of the flag, you should first convince upstream to change it.

BTW, Aruba has now fixed the issue with their RADIUS software. From our network team:

> We're running Aruba Clearpass version 6.9.10 and the version with the fix is 6.9.11.   We've got this loaded in our Lab for testing now and will roll out to production as soon as we get approval.
> 
> Below are the BugIDs associated with the issue.
> 
> CP‑44097
> CP‑45720
> CP‑46102
> CP‑46369
> 
> Corrected an issue where newer Linux supplicant versions (wpa_supplicant-2.10 and later) failed 802.1x authentications with the EAP‑PEAP protocol because those clients did not accept legacy (insecure) TLS re-negotiation.
> 
> ClearPass now supports secure TLS re-negotiation.

Our network team deployed 6.9.11 last weekend, so if 6.9.11 does indeed support secure renegotiation, then I can no longer help troubleshoot work-arounds for RADIUS servers that do not…

(In reply to James Ralston from comment #60)
> 3. As a consequence of #2, insecure TLS renegotiation is solely a *server*
> vulnerability. A TLS client that does not support RFC5746 can help enable
> the attack, but is not vulnerable to it.

Sort of? Very bad things happen to the client as a result of the attack when used with HTTP. I guess PEAP is probably safer?

(In reply to James Ralston from comment #60)
> 3. The "allow_unsafe_renegotiation" name was picked by upstream (see my
> comment #48), and it would be even more confusing if Fedora were to name it
> differently than other distros. If you want to change the name of the flag,
> you should first convince upstream to change it.

Yes definitely. Upstream added that flag in response to this issue, so hopefully they are watching....

(In reply to James Ralston from comment #60)
>
> But most importantly:
> 
> 3. The "allow_unsafe_renegotiation" name was picked by upstream (see my
> comment #48), and it would be even more confusing if Fedora were to name it
> differently than other distros. If you want to change the name of the flag,
> you should first convince upstream to change it.

We certainly would fix it upstream first, that is no problem.

As far as NetworkManager is concerned, this is only on the `main` branch and there was no stable release yet. That makes it especially easy to "break" it.

Anyway. What is still unclear to me, how the option should look like in NetworkManager's API. Should we rename then? 

> 1. End users don’t care (and arguably, shouldn’t have to care, as NetworkManager should work with wpa_supplicant to automatically enable "allow_unsafe_renegotiation" if it is required).

Does this mean, the option shouldn't even exist on the NetworkManager API, and NetworkManager+wpa_supplicant should figure out the desired behavior automatically? That would be always preferable. How do we achieve that?

(In reply to Thomas Haller from comment #63)
> Anyway. What is still unclear to me, how the option should look like in
> NetworkManager's API. Should we rename then? 

Yes, I think so, because you have a semantic mismatch. The name of the NetworkManager option nicely matches the wpa-supplicant option, but the name of the wpa-supplicant option does not match the OpenSSL flag that it is using. Both projects should name this option "allow_legacy_servers" or something similar instead. It looks like the flag only affects servers that do not support secure renegotiation *today*, but it's almost certain to affect a lot more than that in the future, so the current NetworkManager and wpa-supplicant names are just not right.

If the new wpa-supplicant option is already stable API, then it should toggle SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION instead of SSL_OP_LEGACY_SERVER_CONNECT in order to match the name of the option. But that is not ideal, because that is more than what was needed to fix this bug.

> Does this mean, the option shouldn't even exist on the NetworkManager API,
> and NetworkManager+wpa_supplicant should figure out the desired behavior
> automatically? That would be always preferable. How do we achieve that?

I thought so, but I was wrong: see comment #54 where "Need Real Name" (nice name) corrected me. There are actual direct security implications to enabling this setting, and only severely outdated servers should have this problem, so the current NetworkManager/wpa-supplicant/OpenSSL behavior seems reasonable. James seems to think that it should be hard to exploit, but I don't know.

As I just wrote on bug 2077973#c24:

NetworkManager should detect whenever wpa_supplicant calls eap_notify_status(sm, "unsafe server renegotiation", "failure") and then do one of the following:

1. Automatically retry wpa_supplicant with allow_unsafe_renegotiation=1, without any user notification.

2. Advise the user that the connection attempt will succeed if the user sets the (e.g.) “permit unsafe legacy server connections (no RFC5746)” NetworkManager option for the connection.

The motive for #2 is to ensure that the user is OK with connecting to a Wi-Fi network with known security deficiencies, but an ulterior motive is to motivate users to pressure the operators of the Wi-Fi network to correct those deficiencies.

In terms of the name of the option, I asked hostap upstream if they are willing to rename it:

http://lists.infradead.org/pipermail/hostap/2022-July/040665.html

If they say yes, I will submit a patch to upstream to rename the option name from “allow_unsafe_renegotiation” to “allow_legacy_server_connect”.

I reverted the flag in NetworkManager ([1]).

That's because 1.40.0 release is getting closer, and it seems we want at least rename the flag.

The patch itself is trivial, and we can do a similar solution (and even backport to a minor release like 1.40.2 -- usually we don't bring new features to minor releases, but just a flag is a very small API where we can do that if necessary)

[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/3117198f157835506eb1819937b01d68c9e36038


Thanks James. FWIW, I think your mail to hostap list is very good, I agree with your proposal.

Thanks everybody for raising this issue.

from an end-user:

Thanks for all the work. I edited the config file, no succes. The nm-connection-editor does no show a checkbox to fall back to "obsolete" security. 

Question: Is this bug fixed in FC36, updated on august 19 ? Or should I install some fixes (from some repository) and edit some config files ?

Thanks in advance