network manager peap mschapv2 authentication stopped working

[Vincent Gerris]

Probably in a recent update, the connection to our MSCHAPv2 / PEAP network with security set to WPA/WPA2 Enterprise.
It worked a few weeks back, but not any more.
Many users have issues that are posted here:
https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1104476

Decided to make a new bug report because it is probably a new issue.

Trying to connect fails and throws another screen where the password can be filled in.

[Vincent Gerris (vgerris)]

Certificate checkbox to keep ignoring does not work either by the way.
Ran this wireless info script: https://raw.githubusercontent.com/UbuntuForums/wireless-info/master/wireless-info
change the file to some other name, it writes to that name.

Please find my info attached, removed some info that is not relevant or private.

[Franko Burolo (fburolo)]

I don't believe this is certificate-related this time. In the linked bug Zacharias Steinmetz says: "Same on my PC running Vivid (3.19.0-22, BCM4313), both with certificate added and ignored."

In my case, it is a Toshiba Satellite C50-B-15N with Vivid 64, same kernel version as Zacharias, but a Qualcomm Atheros card (Qualcomm Atheros QCA9565 / AR9565 Wireless Network Adapter (rev 01), running with the ath9k module).

Walter Garcia-Fontes suggested on the linked bug that this new one could be hardware-specific, but here we see that the issue comes up with at least two different brands of wifi cards, i.e. Atheros and Broadcom.

[Launchpad Janitor (janitor)]

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

[Vincent Gerris (vgerris)]

I agree, note that the ignore always checkbox still does not work.
Our connection does not require a certificate and it simply works on Android and Fedora Linux.
Quite some users posted this not working since a few weeks, it might be a firmware change or kernel update.
I was unable to figure out on a short term how to load the newer firmware I found in the belonging dir in the other thread.

[Franko Burolo (fburolo)]

You mean the ignore CA certificate checkbox? On my system it seems to work fine. If checked, it doesn't ever ask for a cert; in the edit connections window, under the wireless security tab, the "No CA certificate is required" checkbox remains checked; and there is no mention of CA certs in /etc/NetworkManager/system-connetcions/[NetworkName]. So this bit seems fine to me. What's bothering me, is that nonetheless it just doesn't connect anymore. I can't check if using a cert would make any difference, as my faculty doesn't provide one. But I assume Zacharias did test it both ways (CA and no-CA), getting same results.
It could easily be related to a kernel update, though. Or to a NetworkManager one, since this is happening on at least three differently branded cards: your Intel, my Atheros and Sacharias' Broadcom. And all three brands are VERY common, btw...

[Vincent Gerris (vgerris)]

A colleague of mine reports this is broken in Fedora 22 too after fully upgrading to the latest packages.
He did a reinstall and did not upgrade the following packages:
 - wpa-supplicant
 - network-manager-ovpnc

Then in kept working.

So maybe something was changed upstream that broke this?

[Franko Burolo (fburolo)]

This would indicate it is an upstream bug, after all. Is there anybody able to try the same with Vivid?

I might be wrong, but I don't believe this is wpa-supplicant-related, because there were reports of being able to connect manually with wpa-supplicant, from CLI. So it is most likely NetworkManager's fault... again. But it could also be some change in wpa-supplicant that broke communication between the two.

[Vincent Gerris (vgerris)]

Not sure. When I try the wpa_supplicant config workaround, I get all kinds of SSL errors, with or without ca_cert option.
Tried a SSL downgrade with no success just to test.
OpenSSL: openssl_handshake - SSL_connect error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small
and another one about the CA not verifyable.
I simply have no time now to dig deeper, I hope someone figures this out because it is very annoying.

[marbertone (marbertone-deactivatedaccount)]

affects me too. I am available to give support for debug!

[Vincent Gerris (vgerris)]

Somebody posted this in the other bug report:
Jiminy crickets, kernel upgrade to 3.19.0-23 and EDUROAM is picking up again!

I have not had time to test it yet, maybe anyone else can try that and post back?

[Vincent Gerris (vgerris)]

I tried this by doing :
sudo apt-get install linux-generic-lts-vivid
I got :
3.19.0-26 as a kernel.
Rebooted and tried, but I have the same issue.

[Maris Nartiss (maris-nartiss)]

According to a RH bug description, the problem lies on the server side of connection.

Quote: " wpa_supplicant 2.4 may trigger this where 2.3 would not, becuase 2.4 enables some new ciphers for use with TLSv1.2, and the server may have enabled DH only for those ciphers that are now enabled.

The options are to either get your network admins to fix the DH key issue by using something > 768 bits, or to disable TLSv1.2 for now until they fix it."
https://bugzilla.redhat.com/show_bug.cgi?id=1241930

Too short DH key issue affects many programs (google it - sendmail, postfix, mysql etc.)

Currently only option seems to be to downgrade wpa_supplicant to 2.3 as it seems to work and wait till a) a failback mechanism will be implemented to use older (and insecure!) TLS or SSL if TLS 1.2 fails or b) all eduroam RADIUS servers will be upgraded (more like never).

[Vincent Gerris (vgerris)]

I am running Ubuntu 14.04 LTS with 2.1-0ubuntu1.3 for wpasupplicant so not sure if that is it?

[Vincent Gerris (vgerris)]

I also tried https://packages.debian.org/sid/wpasupplicant (2.3 debian package), rebooted and tried, but no luck.
Might it be OpenSSL related? Seems an Ubuntu issue still, on Fedora it seems to work with 2.3 and openssl1.0k .
I did not find a newer package quickly, and I do not want to start compiling from source now, so I hope an Ubuntu developer picks this up.

[Vincent Gerris (vgerris)]

I cannot imagine Canonical is benefiting from this Enterprise Authentication not working.
Is there any way to escalate this to Canonical?
I am sure if they are aware it may get some priority?
We really need a work around.
I may really need to leave the distro otherwise, just for the sake of working wireless and multi display support, that also works already in Fedora.
I don't mind doing a dist upgrade if that fixes it, but this is getting nowhere.

[Vincent Gerris (vgerris)]

Still an issue on 14.10 with wpa_supplicant 2.3.
It seems to be cause by SSL enforcing a higher DH key length (>768 bit).
Although I tried the non-updated version 1.0.1f (0.9 instead of 0.9.8) the behaviour is still the same.

Should indeed be fixed on the server side, a new DH key should be generated.
More info : https://weakdh.org/

I tried working around it by having TLS 1.2 disabled but that did not work for me.
I suppose Windows and Android users are still happily exposed, but us Linux users can simply not use the wifi network with poor security setup.

I read it might be worked around to by compiling wpa_supplicant with gnutls, I am not going to try.
I filed an internal request to fix the key here, hope it will be done, because it may depend on hardware firmware availability.

If anyone found a way to make wpa_supplicant deal with this, or openssl (without a downgrade) please post your workaround.

Network-manager is missing phase1 settings, so you have to stop it and use wpa_supplicant like:
 wpa_supplicant -i wlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf

[Vincent Gerris (vgerris)]

Apparently Aerohive is one of the companies that has not released new firmware for their access point, and have known about it for a few months:
https://community.aerohive.com/aerohive/topics/dh-key-too-small
If you found them or any other not to have a patch in place, please contact their support and notify them of the importance.
This is a rather big security issue.
thank you.

I suppose this bug can be marked as invalid