wpa can't connect to servers using TLS 1.1 or older

Still an issue with the new wpasupplicant 2:2.10-2 package.

Status changed to 'Confirmed' because the bug affects multiple users.

Getting the same issue using Qualcomm Atheros modem on WPA university WLAN network. Confirmed that same settings and hardware work fine with Ubuntu 21.10.

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1958267

Thank you for your bug report, do you have details on what sort of configuration and security options is eduroam using?

Could you edit /lib/systemd/system/wpa_supplicant.service to add a '-d' to the ExecStart cmd, restart, try to connect and share the 'journalctl -b 0' log from the system?

Eduroam is a WPA2 Enterprise network. It supported different EAP methods (https://wiki.geant.org/pages/viewpage.action?pageId=121346284):

- EAP TTLS-PAP
- PEAP
- EAP TLS
- EAP-pwd

I always use the default option selected in Ubuntu Wi-Fi Settings, which is labeled "Tunneled TLS". But I double-checked some guides and most recommend PEAP, which I've now also tried and had the same issue with.

Guide from my institution: https://it.umn.edu/services-technologies/how-tos/wifi-connect-unix-or-linux-most-major
Another guide: https://www.ucl.ac.uk/isd/how-to/connecting-to-eduroam-wi-fi-linux

I usually use the "No CA certificate is required" option as shown in the second guide.

The "Inner authentication" is the default option, MSCHAPv2.

Log attached. Thanks!

Jeremy pointed out https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907 which could be similar

bug #1962541 seems a bit similar though the log here includes

> OpenSSL: openssl_handshake - SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled

I've reported it upstream now on http://lists.infradead.org/pipermail/hostap/2022-March/040305.html

The unsafe legacy disabled suggests it could be bug #1963834 and a choice from upstream openssl to disable unsafe servers, maybe that's something the eduroam admins need to sort out?

I can confirm that using this workaround and restarting wpa supplicant solved the connection issues for me: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834/comments/7

The workaround also does work for me. (For the record, I appended those lines at the end of the config file.)

I see the openssl bug is marked wontfix. I think this is unfortunate, since it means that eduroam (maybe poorly configured, but still) will work out of the box for Windows and Mac (and Android and iOS) but not Ubuntu 22.04 LTS.

@Hans, @Alexander, could any of you contact one of the eduroam admins to report the issue? Ideally they would just fix their servers, currently the fact that it works under windows doesn't resolve the fact that they are using an insecure configuration and should be fixed

@Sebastian, I have this issue with the EAP-TLS protected network of at work, its not eduroam. I'll see if I can reach any of the network admins.

However, I doubt that the servers are configured to use insecure methods; there were lots of security related changes done in the past year to the wifi infrastructure, including the roll out of EAP-TLS over PEAP. There is basically zero legacy support in this wifi currently.

Can you tell me how to check what insecure configuration is actually the problem here?

I've opened a ticket with my University's IT dept with the suggestion.

@Hans, you should probably open a new bug with a debug log attach as described in comment #6 so we can ensure it's the same issue you are seeing

I won't attach a full system log of my work machine. I can confirm however that I get the same "wpa_supplicant[3600]: OpenSSL: openssl_handshake - SSL_connect error:0A000152:SSL routines::unsafe legacy renegotiation disabled" error, even without the -d flag.

@Hans, fair enough. Googling for that error the first result here is https://www.ibm.com/mysupport/s/question/0D50z000062ktWGCAY/why-ssl-handshake-fails-with-unsafe-legacy-renegotiation-disabled
which states

'This error means that the SSL server does not support the Renegotiation Indication Extension (RFC 5746) and therefore is vulnerable to man-in-the-middle attacks (CVE-2009-3555).

You will need to make sure the server is upgraded to support RFC 5746'

maybe you should try to contact your sysadmin to ask if that's the case?

Internet also suggests other recent distributions will have the same issue, https://ask.fedoraproject.org/t/cannot-connect-to-wpa2-enterprise-university-wifi-on-fedora-36 for example

@seb128

Sorry if that sounded browbeating. My response is more like "unfortunate, but understandable". Someone has to be first, even if MS/Apple seem OK to leave it working.

Thanks for finding the Fedora info. I had just wondered about other distros. Looks like the other bug they link to is a dupe of this? https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1961558

Can I suggest this be documented in the release notes, at least the issue, but maybe even including the workaround? FWIW, I see now the file suggested in the workaround above (/usr/lib/ssl/openssl.cnf) is a link to /etc/ssl/openssl.cnf, so I think it shouldn't get overwritten as I thought it might.

FWIW my university's support team replied that they don't support Linux devices but they would forward my message to the network team. I haven't heard anything since.

I use the following method to bypass this bug，
1. create openssl.cnf for wpa_supplicant
- sudo cp /etc/ssl/openssl.cnf /etc/wpa_supplicant/
- motify /etc/wpa_supplicant/openssl.cnf
*** /etc/ssl/openssl.cnf Fri Apr 22 14:54:42 2022
--- /etc/wpa_supplicant/openssl.cnf Fri Apr 22 14:55:22 2022
***************
*** 52,57 ****
--- 52,64 ----

  [openssl_init]
  providers = provider_sect
+ ssl_conf = ssl_sect
+
+ [ssl_sect]
+ system_default = system_default_sect
+
+ [system_default_sect]
+ Options = UnsafeLegacyRenegotiation

  # List of providers to load
2. modify /usr/lib/systemd/system/wpa_supplicant.service
***************
*** 8,13 ****
--- 8,14 ----
  [Service]
  Type=dbus
  BusName=fi.w1.wpa_supplicant1
+ Environment="OPENSSL_CONF=/etc/wpa_supplicant/openssl.cnf"
  ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant
  ExecReload=/bin/kill -HUP $MAINPID
3. restart wpa_supplicant
sudo systemctl daemon-reload
sudo systemctl restart wpa_supplicant.service

I am facing a similar problem after upgrading my Laptop from 21.10 to 22.04. I lost Wifi during the upgrade process, which also meant that refreshing the snap packages failed. But I was unable to connect to my Wifi again, even after reboot. I have a Unifi network set up for WPA enterprise, using a Let's encrypt certificate. It works fine on all my Windows machines and all machines on older Ubuntu.

I tried the work-around in comment #22, but sadly it does not work for me. I am seeing an "internal error" in syslog:

Apr 23 10:41:31 thomas-laptop wpa_supplicant[3116]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal error
Apr 23 10:41:31 thomas-laptop wpa_supplicant[3116]: OpenSSL: openssl_handshake - SSL_connect error:0A0C0103:SSL routines::internal error
Apr 23 10:41:32 thomas-laptop wpa_supplicant[3116]: wlp0s20f3: CTRL-EVENT-EAP-FAILURE EAP authentication failed
Apr 23 10:41:32 thomas-laptop kernel: [ 431.697248] wlp0s20f3: deauthenticated from xx:xx:xx:xx:xx:xx (Reason: 23=IEEE8021X_FAILED)

I attached my full /var/log/syslog output.

I recently upgraded to 22.04 on a fresh install and ran into this bug. I am a network administrator at my work and was able to determine on the authentication server was seeing TLS related errors.

I made the changes supplied by user nfalse and was able to connect right away.

I am willing to test new packages to help squash this behavior.

On a Thinkpad X230 I had this problem after upgrading to 22.04.

The recipe in comment 23 by nfalse solved the problem for me.

Thank you (though this is only a temporary workaround, given its use of "UnsafeLegacyRenegotiation")

Whoops -- actually, my enterprise network was a university's main wifi (wpa.mcgill.ca), not eduroam. I propose to generalize the title of this bug by dropping eduroam or changing it to (e.g. eduroam)

See also https://bugzilla.redhat.com/show_bug.cgi?id=2069239. For those that have this problem with the "0A0C0103:SSL routines::internal error" message, check whether your radius server possibly only supports TLS 1.1 or older. Those servers would default to rsa_pkcs1_md5_sha1 as TLS signature algorithm, which does not meet the 80 bits of security requirement of OpenSSL 3's default SECLEVEL of 1.

Try setting SECLEVEL to 0 to see if that fixes the issue for you. Talk to your Radius server administrator to recommend they offer TLS 1.2 or higher.

I was also affected by this issue when updating from 21.10 to 22.04, not on eduroam but on my university's network.
Workaround from post #22 worked for me, but I simply modified the original file (/etc/ssl/openssl.cnf).
After reading other comments, I got confused. Is this a bug on Ubuntu's wpasupplicant or a problem with the university's infrastructure using old vulnerable authentication methods?
If the latter, how should I report it to university's sysadmin?

It's definitely the infrastructure that's using old TLS. As for the unsafe renegotiation, that happens because the server does not send a renegotiation_info extension in its ServerHello message. See https://datatracker.ietf.org/doc/html/rfc5746. See specifically section 4.1, which discusses client behavior. OpenSSL 3 defaults to the secure client behavior, which requires the server to support RFC5746.

For the "0A0C0103:SSL routines::internal error" the issue is that these servers only offer TLS 1.1 or older, which uses MD5-SHA1 as digest in its signature algorithm. Due to recent collision attacks on SHA1, this no longer meets OpenSSL default level of security of 80 bits (see https://sha-mbles.github.io/, which reduced the chosen-prefix collision to 63.4 bits).

I applied comment #22 WA but it didn't work me.

The workaround from post #22 doesn't work for me too :(

The workaround linked to in #11 has worked for me: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1963834/comments/7

Can someone explain how to fix "0A0C0103:SSL routines::internal error" ?

Upgraded to 22.04 and started facing issues w.r.t. WiFi.
Steps in comment #22 did not work for me.

Fresh install of 22.04 and enterprise wifi at work is no longer working.
Steps in comment #22 did not work for me.

For those for whom the steps in #22 didn't work, does adding the following line in /etc/wpa_supplicant/openssl.cnf right below the "Options = UnsafeLegacyRenegotiation" line work?

CipherString = DEFAULT@SECLEVEL=0

(that's in addition of the other steps outlined in #22)

Simon, I tried your suggestion followed by running sudo systemctl restart wpa_supplicant.service and I still am unable to connect.

I'm happy to say that the approach outlined in #22 worked for me. I used the CipherString option in #36, too, but didn't try without. Glad I found this thread.

The network in question is UC Berkeley's eduroam.

Thanks for the suggestion Simon, but unfortunately, #22 + #36 + reboot didn't work for me (I'm trying to connect to eduroam's WIFI).

I tried also #22 + #36 + reboot, still having "0A0C0103:SSL routines::internal error"

My bad, this should have been DEFAULT@SECLEVEL=0. I'll edit my comment.

Thank you all for your tests, it's much appreciated!

@seb128 My University closed my ticket after I confirmed the workaround works to get connected :-/ I'm not 100% sure they understood the real source of the issue. I replied, but don't have a big expectation that they will do anything. Hopefully someone at another institution that also uses eduroam is successful at getting the needed changes made and that they propagate to other institutions.

Simon, I changed it to DEFAULT@SECLEVEL=0 and ran sudo systemctl restart wpa_supplicant.service, but unfortunately it did not make any difference.

Also tried seclevel=0 and go no success.

Same for me... I have the same problem on two different computers that I just updated to 22.04.
(for me, the error message is :
Apr 30 11:12:58 pop-os wpa_supplicant[4391]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal error

Apr 30 11:12:58 pop-os wpa_supplicant[4391]: OpenSSL: openssl_handshake - SSL_connect error:0A0C0103:SSL routines::internal error
)

see also https://bugzilla.redhat.com/show_bug.cgi?id=2072070 for lengthy discussion.

Same for me. I try to add workaroung in #22 but

May 2 15:02:12 KLINGON wpa_supplicant[10086]: SSL: SSL3 alert: write (local SSL3 detected an error):fatal:internal error
May 2 15:02:12 KLINGON wpa_supplicant[10086]: OpenSSL: openssl_handshake - SSL_connect error:0A0C0103:SSL routines::internal error

Unsure if this helps. I too have this issue with my university's wifi. I was able to work with one of the networking people in the tech center and we found that 22.04 would not even show up as attempting to connect on their end, (and we verified that 21.10 successfully connected as expected. Unsure how much this helps but I thought it would be useful information.

I also solved the problem with [nfalse (nfalse) wrote on 2022-04-22: ].
Thank you so much!

This affects WiFi hotspot as well. After downgrading to wpasupplicant_2.9.0-21build1_amd64.deb my phone can connect to the WiFi hotspot.

For having the command quickly about downgrading wpasupplicant, what solved my issue temporarily:

sudo cat <<'EOF' | sudo tee /etc/apt/sources.list.d/impish.list
deb http://archive.ubuntu.com/ubuntu/ impish main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ impish-updates main restricted universe multiverse
deb http://archive.ubuntu.com/ubuntu/ impish-security main restricted universe multiverse
EOF

sudo apt update
sudo apt -y --allow-downgrades install wpasupplicant=2:2.9.0-21build1
sudo apt-mark hold wpasupplicant

it would be easier to wget, dpkg -i the deb rather than change the sources...

There are thousand ways to do stuff in linux era :D, I have picked one.

To clear the mark and the impish repo:
sudo rm -f /etc/apt/sources.list.d/impish.list
sudo apt-mark unhold wpasupplicant

After they have released the updated package.

@seb128

I got another reply from someone up the chain:

    We use TLS for the outer tunnel for 802.1x. The inner tunnel is
    connecting using AES with rotating keys. The work around is all
    that we can offer at this time as we are waiting for an update
    from the vender as to where this is on their roadmap.

The 'unsafe legacy renegotiation disabled' error impact PEAP authentifications and has been discussed in details on https://bugzilla.redhat.com/show_bug.cgi?id=2072070#c24

There is a specific report about PEAP, bug #1962541

We will issue an update similar to what fedora did in https://src.fedoraproject.org/rpms/wpa_supplicant/c/2a2d1848 to address those specific issues

The 'unsafe legacy renegotiation disabled' error is one of error mentioned in this bug report. Another one is 'SSL_connect error:0A0C0103:SSL routines::internal error' after enabling legacy renegotiation.
This issue is discussed in Fedora's Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2069239

Adding patches:
- https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0049-Allow-disabling-of-SHA1-signatures.patch
- https://src.fedoraproject.org/rpms/openssl/blob/rawhide/f/0052-Allow-SHA1-in-seclevel-1-if-rh-allow-sha1-signatures.patch
and including `rh-allow-sha1-signatures = true` in `openssl.cnf` fixed problem for me.

I'm not sure if we have the same issue or better if the bug has the same cause.
We installed a ubuntu 22.04 and added a hotspot via nmcli.

The hotspot is visible, but we can't connect with any devices.
As soon we change the security from "WPA & WPA2" to "None" we can connect without any issues.
If we choose "WPA3 Personal" we get the error message that the password is invalid (which is not the case).

With 20.04 it works fine (because it still use 2.9-1ubuntu4.3)!
Is there any ETA for the new (fixed) version ?

@Dustin, could you do a new report using
$ ubuntu-bug wpasupplicant
?

then edit /lib/systemd/system/wpa_supplicant.service to add a '-d' to the ExecStart cmd, restart the system, trigger the bug and add the journal log

$ journalctl -b 0 > log

Solution https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/comments/22 didn't worked for me. Installing this https://launchpad.net/ubuntu/+source/wpa/2:2.10-6ubuntu1 didn't worked for me as well. Downgraded following instructions from https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/comments/51 and then reboot worked.

@Ian and everyone else, better to report a new bug following the instruction I just posted before, your issue is probably different from the one originally posted here and mixing the discussions is creating confusion

Hello,
I can confirm the https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1962541 proposed package is fixing legacy renegotiation issue in WPA Enterprise where MSCHAPv2 + PEAP are used in authentication.

This issue is duplicate for WPA 802.1x failure can be linked to https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1962541

I do not get any window for password entering on eduroam network and authentication goes smooth without any manual intervention or custom changes such as Comment 22.

Comment #51 fixed all my problems.
unsafe legacy renegotiation disabled & SSL_connect error:0A0C0103:SSL routines::internal error

For those of us who used the workaround method by @nfalse in comment 22, how and when do we undo this workaround so as to be safe and benefit from the released fix?

"Changed in wpa (Ubuntu):
status: Confirmed → Fix Released"

I am not sure how I did this, I am not an admin and was by complete accident. I contacted Sebastien to correct this and bring it back to the original status of "Confirmed". My apologies.

Retitling this report to focus on the issue connecting to TLS <= 1.1 servers, which is reported upstream now on http://lists.infradead.org/pipermail/hostap/2022-May/040563.html

I updated to wpasupplicant 2:2.10-6, and I was able to undo the modifications from #22 and still connect normally using PEAP and MSCHAPv2 authentication, confirmed by restarting wpasupplicant service and reboot.

Somewhat related, using a NetworkManager Wifi Hotspot, latest Apple devices refuse to connect unless I downgrade to Impish version of wpa_supplicant and libssl1.1.

Other workarounds detailed here do not solve it.

could you report a new bug about the hotspot issue including a debug log? there is also bug #1972790 and https://mail.gnome.org/archives/networkmanager-list/2022-March/msg00016.html which is going to be fixing in the next network-manager but if downgrading wpa resolves the issue for you then it's probably another bug

@Sebastien Bacher
Is there any ETA for the next network-manager version on ubuntu 22.04 ?

@Dustin, do you have a specific issue that you believe is solved with a newer NetworkManager?

We updated kinetic to 1.38 earlier this week which was a prerequired and upstream rolled a stable update in the 1.36 yesterday which should be uploaded later today, then it needs to get reviewed and accepted

Sebastien wrote "which is going to be fixing in the next network-manager".
Maybe i misunderstood the post?

We updated kinetic to 1.38 earlier this week which was a prerequired and upstream rolled a stable update in the 1.36 yesterday which should be uploaded later today, then it needs to get reviewed and accepted

The n-m update is fixing the case where 'Only devices that support WPA3 are able to connect to the AP' but for example Ricardo said that downgrading wpa_supplicant fixed the problem for him which means there is also an issue with wpa in some cases. In any case those issues are not what the current bug is about so please report a new ticket with a debug log, we will mark them duplicates of existing reports if needed

The n-m SRU is available for testing now, https://bugs.launchpad.net/bugs/1974428

I've uploaded a candidate patch proposed upstream for testing to kinetic, could those having the issue try if the deb on https://launchpad.net/ubuntu/+source/wpa/2:2.10-9ubuntu1/+build/23801450/+files/wpasupplicant_2.10-9ubuntu1_amd64.deb resolve the connection problems? the deb should install without issue on the LTS

I've just installed 2:2.10-9ubuntu1 amd64 and I can confirm that it works on Kubuntu 22.04 LTS for my university's WPA2 Enterprise network.

Confirm #76 Works for me with enterprise Wifi.

#76 also works on my work's WPA2 Enterprise. PEAP Authentication, No CA cert required; Auto PEAP; MSCHAPv2 inner authentication with user & pass entered. 22.04 Jammy.

#76 works here too

Thanks for the testing and feedback, I've uploaded the fix in the SRU reviews queue now

This bug was fixed in the package wpa - 2:2.10-9ubuntu1

---------------
wpa (2:2.10-9ubuntu1) kinetic; urgency=medium

  * debian/patches/lower_security_level_for_tls_1.patch:
    - set the OpenSSL security level to 0 if that is the only option to
      continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed
      in wpa_supplicant default configuration and OpenSSL 3.0 with the
      constraint on MD5-SHA1 use. Patch proposed by Jouni Malinen on
      the upstream mailinglist (lp: #1958267)

 -- Sebastien Bacher <email address hidden> Tue, 31 May 2022 16:03:29 +0200

WPA2 Enterprise PEAP wifi working great with solution https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1958267/comments/76. Thanks for the great work Sebastien!

Hello Alexander, or anyone else affected,

Accepted wpa into jammy-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/wpa/2:2.10-6ubuntu2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed-jammy to verification-done-jammy. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-jammy. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

Is 2:2.10-6ubuntu2 the same as 2:2.10-9ubuntu1 in #76?

-6ubuntu2 is the version that will get to Jammy (22.04), 9ubuntu1 is the version currently in the devel series (future Kinetic, 22.10).

In general it is preferable to use the version compiled for your current series, even though using the one in -devel might make sense in a testing context, as was the case here.

I enabled propsed and updated wpasupplicant to 2:2.10-6ubuntu2 and I'm now able to connect to the corporate WiFi network again. Thanks!

Added -proposed, updated, and eduroam is happy again. Nice to have something to tell the Ubuntu-wielding students/faculty/staff until we get 'round to upgrading our Radius servers. Thank you for the fix!

The fix doesn't work for me. I still have to set phase1="tls_disable_tlsv1_0=0" in a manual config, because I haven't found out how to set it with the dbus integrated config. It seems it actually uses TLSv1.2 instead of TLSv1.0, but TLSv1.0 being enabled on the client also enables the rsa_pkcs1_sha1 signature algorithm. I haven't been able to reconfigure the supported signature algorithms with a manual openssl config file by setting SignatureAlgorithms = rsa_pkcs1_sha1:RSA+SHA1.

Niklas, thank you for those additional details. Could you file a new bug with those details? You can run this command to start the bug report:

ubuntu-bug wpasupplicant

This bug was fixed in the package wpa - 2:2.10-6ubuntu2

---------------
wpa (2:2.10-6ubuntu2) jammy; urgency=medium

  * debian/patches/lower_security_level_for_tls_1.patch:
    - set the OpenSSL security level to 0 if that is the only option to
      continue the TLS negotiation, i.e., when TLS 1.0/1.1 are still allowed
      in wpa_supplicant default configuration and OpenSSL 3.0 with the
      constraint on MD5-SHA1 use. Patch proposed by Jouni Malinen on
      the upstream mailinglist (lp: #1958267)

 -- Sebastien Bacher <email address hidden> Fri, 03 Jun 2022 23:28:07 +0200

The verification of the Stable Release Update for wpa has completed successfully and the package is now being released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

Thank Kuradakis (p-alexandrosz) #51, I can connect to Hotspot in ubuntu 2204 LTS from my android 11
phone, originally my phone connect error message: connect time exceed - try later, now its ok at all.
p.s: I had to edit minor correction at #51: original deb http://archive.ubuntu.com/ubuntu/ impish ..... to deb http://old-releases.ubuntu.com/ubuntu impish .....) and downgrade work perfectly.