blog.kennypearce.net

XpressConnect, WPA Enterprise, and Debian

We interrupt our not-so-regularly scheduled philosophy to bring you this report about the travails of Linux users on university computer networks.

The Situation

My university is in the process of switching its wireless network to WPA enterprise with EAP-TLS. As I understand it, this move buys significant advantages in wireless security at the expense of more complicated client-side configuration. In particular, each client has to generate a public/private key pair for cryptography. Also, a public CA certificate has to be installed to allow the client to recognize legitimate nodes on the university network. Needless to say, doing this kind of setup by hand is beyond the reach of most users.

To solve this problem, the university deploys a piece of software called XpressConnect. The way it works is that you first connect to an open wireless network where you are redirected to a web page to login and register your computer, at which point you can download the software to automatically configure your wireless settings. (There are some rather obvious security issues here: a bad actor could set up a decoy network and trick users into installing malware. This is especially problematic since the university is here actually telling users to install a new CA certificate, so a bad actor could pull THAT trick without raising any questions, even for somewhat savvy users. But leave that aside - I just needed the blasted thing to work.) An obvious problem here is that this requires your computer to be able to run the software. The university does not provide any means of obtaining the correct certificates without running the software, so manual configuration is effectively impossible. For devices like game consoles that can't run this kind of software, there is a 'media' network that uses a simpler configuration, but the university says they're going to be policing this network and kicking off any device that has a web browser (?!).

Fortunately, XpressConnect runs on a variety of platforms. Configuration on my iPhone was seamless, for instance. It even supports Linux - sort of. That's what this post is about.

Problem 1: Not Ubuntu

I'm running the latest Debian (stretch/sid). The web page for downloading XpressConnect correctly identified my system as 64 bit Linux, and also had a way to download other versions of the software in case it was incorrectly detected. That's good. The page says it supports 32 and 64 bit Ubuntu and Fedora. The differences between Ubuntu and Debian can't possibly matter to a piece of software like this (I thought), especially when it claims to support the last several versions of Ubuntu.

Well, it turns out, the software is trying to detect your exact distro and version, and if you don't exactly match one of the distro/version combinations it recognizes, it refuses to run. There does not appear to be a manual override in the software. (Though maybe it's just undocumented -- there's no '-h' or '--help' or anything to say if the software takes command-line options.) This has been a problem with XpressConnect for at least a few years now. The blog post I just linked gives instructions for spoofing Ubuntu 10.04 (Lucid), but on my machine that caused the software to crash. Apparently, though, Ubuntu 14.04 (Trusty) is similar enough to the current Debian to make the software work. So I created the file /etc/lsb-release (which does not typically exist on Debian) with the following content:


DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04 LTS"


This caused the software to run correctly, installing certificates in my ~/.certificates/ directory and configuring my wifi.

Problem 2: Certificate Woes

Unfortunately, although the software now configured my wifi, the configuration didn't actually work. Instead, it timed out while trying to get an IP address. In /var/log/syslog, I found the following:

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: wlan21: CTRL-EVENT-EAP-STARTED EAP authentication started

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: wlan21: CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=13

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: OpenSSL: tls_read_pkcs12 - Failed to use PKCS#12 file error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: OpenSSL: pending error: error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: OpenSSL: tls_connection_private_key - Failed to load private key error:00000000:lib(0):func(0):reason(0)

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: TLS: Failed to load private key '/home/kenny/.certificates/Secure_WiFiKey.pem'

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: TLS: Failed to set TLS connection parameters
Aug 17 09:29:18 parmenides wpa_supplicant[1312]: EAP-TLS: Failed to initialize SSL.

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: wlan21: EAP: Failed to initialize EAP method: vendor 0 method 13 (TLS)

Aug 17 09:29:18 parmenides wpa_supplicant[1312]: wlan21: CTRL-EVENT-EAP-FAILURE EAP authentication failed

Aug 17 09:29:20 parmenides wpa_supplicant[1312]: wlan21: Authentication with d8:c7:c8:e9:69:d4 timed out.

Aug 17 09:29:20 parmenides wpa_supplicant[1312]: wlan21: CTRL-EVENT-DISCONNECTED bssid=d8:c7:c8:e9:69:d4 reason=3 locally_generated=1

Aug 17 09:29:20 parmenides wpa_supplicant[1312]: wlan21: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="VU-Secure" auth_failures=1 duration=10 reason=AUTH_FAILED


The PKCS12 bit sent me down a lot of rabbit trails, since none of the certificates were PKCS12. After considerable mucking about with OpenSSL, I determined that my public certificate and my private key were mismatched. This appears to have been a result of having run the program several times while I was trying to get it to work. In order to solve this problem, I had to start over from scratch: delete all the certificates the software had created in ~/.certificates, delete the wifi configuration it created, delete XpressConnect, and go back to the web interface to download. Once XpressConnect worked on the 'first' try, I had matching certificates.

Problem 3: Low MTU

And my #%*@ connection still timed out. But now with a new and improved error message in syslog!

Aug 17 11:34:20 parmenides wpa_supplicant[1312]: l2_packet_send - sendto: Message too long

(This printed several times for each connection attempt.) This one does not seem to be the fault of XpressConnect, so I took my problem to the wpa_supplicant folks on the HostAP listserv. wpa_supplicant lead developer Jouni Malinen helpfully responded the same day. Apparently the problem has something to do with a mismatch between the EAP fragment size and the MTU setting on the wireless device. My MTU was set to 1280 (I didn't change it, I don't know how it got like that); I was told the standard setting was 1500. You can set your MTU to 1500 by running (as root) the following command:

ifconfig wlan0 mtu 1500

It appears that NetworkManager generally will not change this value. However, it may not persist across reboots. It is possible to set the MTU specifically for a network configuration in NetworkManager. To do so, right-click the NetworkManager icon and select "Edit Connections..." Edit the connection in question, and select the 'Wi-Fi' tab. At the bottom is a field for MTU. By default it's set to 'Automatic'. Set it to 1500 and hit 'Save'.

Hooray for functioning wifi and a new school year! We now return to our not-so-regularly scheduled philosophy...

Posted by Kenny at August 18, 2015 10:51 AM