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

Bug #1958267 reported by Alexander Browne
232
This bug affects 41 people
Affects Status Importance Assigned to Milestone
wpa (Debian)
New
Unknown
wpa (Ubuntu)
Fix Released
High
Sebastien Bacher
Jammy
Fix Released
High
Sebastien Bacher

Bug Description

* Impact
wpa built with in openssl3 fails to connect to TLS 1.1 or lower server

* Test case
try to connect to a TLS <= 1.1 access point

* Regression potential
the patch lowers the security level in some situation for compatibility, it shouldn't prevent connecting to newer hardware, still try to connect to different type of wifi with different security levels

-----------------------------------------------

those uses MD5-SHA1 as digest in its signature algorithm which no longer meets OpenSSL default level of security of 80 bits

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

Workaround are described in #22 and #36 by basically using
CipherString = DEFAULT@SECLEVEL=0

which lowers the security level

-------

With the current jammy version of wpasupplicant (2:2.10-1), I cannot connect to the WPA Enterprise network eduroam, which is used by Universities worldwide. I get a "Connection failed" message or a request to re-enter the password.

- I've re-tried the credentials: no fix ;-)

- Tried a 21.10 live session on the same machine: works fine!

- Manually downgraded wpasupplicant to the impish version (2:2.9.0-21build1): connected normally.

- Upgraded wpasupplicant to the latest version: fails to connect again.

ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: wpasupplicant 2:2.10-1
ProcVersionSignature: Ubuntu 5.15.0-17.17-generic 5.15.12
Uname: Linux 5.15.0-17-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.11-0ubuntu75
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Tue Jan 18 09:56:23 2022
InstallationDate: Installed on 2021-11-30 (48 days ago)
InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20211130)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: wpa
UpgradeStatus: No upgrade log present (probably fresh install)

CVE References

Revision history for this message
Alexander Browne (elcste) wrote :
description: updated
Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in wpa (Ubuntu):
status: New → Confirmed
Revision history for this message
Raymond Ogunjimi (raymondogunjimi) wrote :

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.

Revision history for this message
Ubuntu QA Website (ubuntuqa) wrote :

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

tags: added: iso-testing
Revision history for this message
Sebastien Bacher (seb128) wrote :

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?

Changed in wpa (Ubuntu):
importance: Undecided → High
status: Confirmed → Incomplete
tags: added: rls-jj-incoming
Revision history for this message
Alexander Browne (elcste) wrote :

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!

Changed in wpa (Ubuntu):
status: Incomplete → New
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in wpa (Ubuntu):
assignee: nobody → Sebastien Bacher (seb128)
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

tags: added: openssl3
Revision history for this message
Sebastien Bacher (seb128) wrote :

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?

tags: removed: rls-jj-incoming
Changed in wpa (Ubuntu Jammy):
status: New → Confirmed
Revision history for this message
Hans Schulz (hschulz) wrote :

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

Revision history for this message
Alexander Browne (elcste) wrote (last edit ):

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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

Revision history for this message
Hans Schulz (hschulz) wrote :

@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?

Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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

Revision history for this message
Hans Schulz (hschulz) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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?

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Alexander Browne (elcste) wrote :

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.

Revision history for this message
nfalse (nfalse) wrote :

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

Revision history for this message
Thomas (tombl) wrote :

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.

Revision history for this message
Nicholas Getchell (ngetchell) wrote :

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.

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

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")

Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

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)

Revision history for this message
Clemens Lang (neverpanic) wrote :

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.

summary: - "Connection failed" for WPA Enterprise network eduroam
+ "Connection failed" for WPA Enterprise network (e.g. eduroam)
Revision history for this message
Victor Hugo Schulz (schulz89) wrote : Re: "Connection failed" for WPA Enterprise network (e.g. eduroam)

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?

Revision history for this message
Clemens Lang (neverpanic) wrote :

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

Revision history for this message
Ahmet Yıldırım (regenx) wrote :

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

Revision history for this message
Ekinoks (ekinoks) wrote :

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

Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Vitor Martins (vmartins0) wrote :

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

Revision history for this message
Chaitanya Rahangdale (chaitanya-lu) wrote :

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

Revision history for this message
Patrick Aoude (aoude) wrote :

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

Revision history for this message
Simon Chopin (schopin) wrote (last edit ):

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)

Revision history for this message
Thomas (tombl) wrote :

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

Revision history for this message
Alex Reinking (alexreinking) wrote :

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.

Revision history for this message
Ekinoks (ekinoks) wrote :

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

Revision history for this message
Vitor Martins (vmartins0) wrote :

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

Revision history for this message
Simon Chopin (schopin) wrote :

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

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

Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Thomas (tombl) wrote :

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

Revision history for this message
Vitor Martins (vmartins0) wrote :

Also tried seclevel=0 and go no success.

Revision history for this message
Paulin (p4ul137) wrote :

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
)

Revision history for this message
Tim Richardson (tim-richardson) wrote :
Revision history for this message
Fox (cmessina70) wrote :

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

Revision history for this message
Thomas (teeaaa) wrote :

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.

Revision history for this message
GyuHyeon Choi (wiany11) wrote :

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

Revision history for this message
Petter Sundlöf (petter-sundlof) wrote :

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

Revision history for this message
Kuradakis (p-alexandrosz) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Kuradakis (p-alexandrosz) wrote :

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.

Revision history for this message
Alexander Browne (elcste) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in wpa (Debian):
importance: Unknown → Wishlist
Revision history for this message
Artur Frysiak (wiget) wrote :

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.

Changed in wpa (Debian):
importance: Wishlist → Unknown
status: Unknown → Fix Released
Revision history for this message
Dustin Utecht (codmdu) wrote :

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 ?

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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

Revision history for this message
Ian Tan Yi Xiong (ianyxtan) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

@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

Revision history for this message
Chinmay Khandekar (cspacews) wrote :

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.

Revision history for this message
Vitor Martins (vmartins0) wrote :

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

Ted DeWitt (tdewitt)
Changed in wpa (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Christopher Barrington-Leigh (cpbl) wrote :

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?

Revision history for this message
Ted DeWitt (tdewitt) wrote :

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

Changed in wpa (Ubuntu):
status: Fix Released → Confirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

summary: - "Connection failed" for WPA Enterprise network (e.g. eduroam)
+ wpa can't connect to servers using TLS 1.1 or older
Changed in wpa (Ubuntu):
status: Confirmed → Triaged
description: updated
Changed in wpa (Ubuntu Jammy):
milestone: none → ubuntu-22.04.1
Changed in wpa (Debian):
status: Fix Released → Unknown
Changed in wpa (Debian):
status: Unknown → New
Revision history for this message
Victor Hugo Schulz (schulz89) wrote :

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.

Revision history for this message
Ricardo Pardini (rpardini) wrote :

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.

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Dustin Utecht (codmdu) wrote :

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

Revision history for this message
Jeremy Bicha (jbicha) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Dustin Utecht (codmdu) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in wpa (Ubuntu):
status: Triaged → Fix Committed
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Matthew Faigan (mfaigan) wrote :

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.

Revision history for this message
Bernardo Ferreira (bernardoferreira) wrote :

Confirm #76 Works for me with enterprise Wifi.

Revision history for this message
Ted DeWitt (tdewitt) wrote :

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

Revision history for this message
Sergio Callegari (callegar) wrote :

#76 works here too

Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in wpa (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Ian Tan Yi Xiong (ianyxtan) wrote :

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!

description: updated
Revision history for this message
Timo Aaltonen (tjaalton) wrote : Please test proposed package

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.

Changed in wpa (Ubuntu Jammy):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-jammy
Revision history for this message
Sergio Callegari (callegar) wrote :

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

Revision history for this message
Simon Chopin (schopin) wrote :

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

Revision history for this message
Jeroen Bruinink (jbruinink) wrote :

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!

Revision history for this message
Bruce H McIntosh (mrz80) wrote :

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!

tags: added: verification-done verification-done-jammy
removed: verification-needed verification-needed-jammy
Revision history for this message
Niklas Keller (nk24) wrote :

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.

Revision history for this message
Jeremy Bicha (jbicha) wrote :

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

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in wpa (Ubuntu Jammy):
status: Fix Committed → Fix Released
Revision history for this message
Brian Murray (brian-murray) wrote : Update Released

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.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.