openssl 1.0.1f-1ubuntu2.15 prevents connection to WPA Enterprise networks

[John B.]

The current version of openssl/libssl in Ubuntu 14.04 (1.0.1f-1ubuntu2.15) breaks wireless connectivity to WPA Enterprise networks at my institution. WPA 2 personal networks are unaffected (my home setup). If I install the "-1ubuntu2.12" version of openssl, libssl (amd64 and i386) I can once again connect to the WPA Enterprise network (I need to manually restart networking via network-manager *and* make sure to kill wpa_supplicant from the command line to make sure that the broken library is no longer loaded).

The WPA Enterprise network in question can be accessed a few different ways. One way uses TLS and certs, the other uses Tunneled TLS, no cert, but a username/password combination. Both methods break upon installing the new openssl & libssl.

I'm marking this as a security vulnerability because the only way (for me) to currently access WPA Enterprise networks is to run an older version of openssl&libssl.

lsb_release -rd
Description: Ubuntu 14.04.2 LTS
Release: 14.04

*Working* version of package:
apt-cache policy openssl
openssl:
  Installed: 1.0.1f-1ubuntu2.12
  Candidate: 1.0.1f-1ubuntu2.15
  Version table:
     1.0.1f-1ubuntu2.15 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
 *** 1.0.1f-1ubuntu2.12 0
        100 /var/lib/dpkg/status
     1.0.1f-1ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

The "candidate" version listed above breaks WPA enterprise.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: openssl 1.0.1f-1ubuntu2.12
ProcVersionSignature: Ubuntu 3.13.0-55.94-generic 3.13.11-ckt20
Uname: Linux 3.13.0-55-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Jun 29 13:05:58 2015
SourcePackage: openssl
UpgradeStatus: Upgraded to trusty on 2014-06-03 (391 days ago)

[Marc Deslauriers (mdeslaur)]

The issue is probably caused by your WPA network using an insecure and easily compromised DH key size.

This is the change that went into the openssl update that is likely causing your issue:
As a security improvement, this update also modifies OpenSSL behaviour to
reject DH key sizes below 768 bits, preventing a possible downgrade
attack.

[John B. (jbuncher)]

1.) Forgive the ignorance, but I'm not sure exactly what a "DH" key is. Is this the key that's involved in the "handshake"?

2.) Would this also prevent logging on via a method that does not use private keys/certs?

3.) Is there a specific error code in the log (and is there a specific log other than the output of dmesg) to look for to verify that keysize is the issue?

4.) If I were to send an email to an admin in IT, how exactly should I phrase the question? Would "What is the bit size of the DH key for the campus WPA netowrk?" be sufficient (with an explanation of the bug and recent openssl patch)?

Thanks!

[Marc Deslauriers (mdeslaur)]

Hi,

1) It's part of the key exchange being used on your wireless network (See https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange )

2) No, I don't think that would affect WPA personal connections, only WPA enterprise connections.

3) "dh key too small" is the string for the error message in openssl, but I'm not sure if that ends up in a log file anywhere.

4) Yes, and you can also refer to the Logjam vulnerability (See https://en.wikipedia.org/wiki/Logjam_%28computer_security%29 )

[John B. (jbuncher)]

I finally heard back from the IT department, and they said that the network uses 2048-bit keys, so I don't think the "reject if less than 2048" is the issue. Is there something else in this patch set that may cause problems? It looks like the connection times out and can never get established.

Is there a package I could test using one patch at a time? Or all but the "autoreject if less than 2048" patch?

[Marc Deslauriers (mdeslaur)]

I've uploaded a package with only the "reject if less than 2048" patch reverted here:

https://launchpad.net/~mdeslaur/+archive/ubuntu/testing

Could you give it a try once it's finished building? Thanks.

Does this bug need to stay private?

[John B. (jbuncher)]

Marc,

I tried the test package and was able to connect to the networks. I installed the following packages from your PPA:

openssl_1.0.1f-1ubuntu2.16~test1_amd64.deb
libssl1.0.0_1.0.1f-1ubuntu2.16~test1_i386.deb
libssl1.0.0_1.0.1f-1ubuntu2.16~test1_amd64.deb

When attempting to use the current Live packages (to confirm if I was still unable to connect) I still could not connect, and there were several lines of the following in dmesg:

[ 102.876831] wlan0: authenticate with 20:bb:c0:2d:60:2f
[ 102.880753] wlan0: send auth to 20:bb:c0:2d:60:2f (try 1/3)
[ 102.896841] wlan0: authenticated
[ 102.899110] wlan0: associate with 20:bb:c0:2d:60:2f (try 1/3)
[ 103.003020] wlan0: associate with 20:bb:c0:2d:60:2f (try 2/3)
[ 103.107071] wlan0: associate with 20:bb:c0:2d:60:2f (try 3/3)
[ 103.211035] wlan0: association with 20:bb:c0:2d:60:2f timed out
[ 107.886677] wlan0: authenticate with 20:bb:c0:2d:60:2c
[ 107.889172] wlan0: send auth to 20:bb:c0:2d:60:2c (try 1/3)
[ 107.982250] wlan0: authenticated
[ 107.985299] wlan0: associate with 20:bb:c0:2d:60:2c (try 1/3)
[ 108.089272] wlan0: associate with 20:bb:c0:2d:60:2c (try 2/3)
[ 108.193176] wlan0: associate with 20:bb:c0:2d:60:2c (try 3/3)
[ 108.297146] wlan0: association with 20:bb:c0:2d:60:2c timed out
[ 108.348444] wlan0: authenticate with 20:bb:c0:2d:60:2c
[ 108.351625] wlan0: send auth to 20:bb:c0:2d:60:2c (try 1/3)
[ 108.399905] wlan0: authenticated
[ 108.400222] wlan0: waiting for beacon from 20:bb:c0:2d:60:2c
[ 108.505063] wlan0: associate with 20:bb:c0:2d:60:2c (try 1/3)
[ 108.608997] wlan0: associate with 20:bb:c0:2d:60:2c (try 2/3)
[ 108.620310] wlan0: associate with 20:bb:c0:2d:60:2c (try 3/3)
[ 108.629430] wlan0: association with 20:bb:c0:2d:60:2c timed out

Would the "reject if DH key too small" patch cause a timeout like this?

Thanks for all of your work so far, it's greatly appreciated. Is there another log I should check, or a specific question I should send on to IT?

[Marc Deslauriers (mdeslaur)]

OK, so that pretty much confirms that the likely issue is your wireless network using a small DH.
I'm not quite sure what else to suggest, since the problem isn't client-side.

[Adrien Nader (adrien)]

Thanks for the analysis and testing. I think we can mark this issue as Won't Fix, especially after all this time.