Cannot connect with updated wpa_supplicant

[ttuegel]

As I previously reported, with no satisfactory response from the package maintainers:

As reported on the hostapd mailing list, wpa_supplicant-2.4 cannot connect to enterprise wireless networks, particularly ones with Cisco equipment. Because the wpa_supplicant developers are refusing to do anything about it, at least one distribution has downgraded to wpa_supplicant-2.3. There is a workaround (see previous link), but it requires users to edit their configurations (which is disruptive) and NetworkManager users (who use wpa_supplicant transitively) cannot do that.

This breaks network connectivity for (at least) NetworkManager users who connect to a Cisco wireless network. I think we can agree, that level of breakage is not acceptable in a stable release. The options I see are (in order of increasing security and effort):

1. Downgrade wpa_supplicant,
2. Keep wpa_supplicant-2.4, but disable TLS 1.2 by default, or
3. Patch NetworkManager to disable TLS 1.2 in wpa_supplicant by default.

[vcunat]

This seems one of the painful cases where the real problem is not in wpa_supplicant, but for now it's easiest to work around from that side.

Personally I'd disable TLS 1.2 by default. If I read it correctly, that's exactly the trigger in 2.4 update, and we'll have less maintenance work than when staying on an older version altogether.

Any idea about the possible switches? If we set CONFIG_TLSV12=n, I suppose it won't be possible to use it at all, even if forced by config, right? Maybe it's not so bad, considering the recent introduction...

[edolstra]

Or apply the patch referenced in http://lists.shmoo.com/pipermail/hostap/2015-May/032748.html?

But disabling TLS 1.2 is also fine I guess.

[vcunat]

@edolstra: if you mean this link http://w1.fi/cgit/hostap/commit/?id=8a78e227df1ead19be8e12a4108e448887e64d6f, that addresses the other issue why Arch reverted to 2.3, and we already do apply the patch since d3e0850.

[devhell]

This is now a problem for me and a few others here at my University. We cannot establish a connection any more with Eduroam. Is there a sane way to get around this issue @ttuegel ?

[wkennington]

The "fix" broke me since I only allow tls1.2 on my radius servers. I wonder
if eduroam is similar.

On Thu, Jun 25, 2015, 01:42 devhell [email protected] wrote:

This is now a problem for me and a few others here at my University. We
cannot establish a connection any more with Eduroam. Is there a sane way to
get around this issue @ttuegel https://github.com/ttuegel ?

—
Reply to this email directly or view it on GitHub
#8332 (comment).

[devhell]

@wkennington Well, it seems that at least our version of Eduroam requires it. This is a major issue now. :-(

[wkennington]

Out of my hands as I've enabled it in my branch and moved on. I can't help
that our policy seems to be to disable a runtime configurable option in the
build itself. Users who have to interface with broken radius servers should
just disable v1.2 in their config.

On Thu, Jun 25, 2015, 01:56 devhell [email protected] wrote:

@wkennington https://github.com/wkennington Well, it seems that at
least our version of Eduroam requires it. This is a major issue now. :-(

—
Reply to this email directly or view it on GitHub
#8332 (comment).

[devhell]

@wkennington Not blaming you. I find it a bit troubling though that some assumptions are made on a whim it seems. But again, I'm not blaming anyone or you in particular.

[ttuegel]

It's not a runtime configurable option if you use NetworkManager.

Honestly, the only "sane" workaround at this point is for everyone to build their own wpa_supplicant.

[vcunat]

I understood that our wpa_supplicant had no TLS-1.2 support until a few weeks ago d3e0850, so I thought re-disabling is unlikely to hurt people. There was only silence on this issue for over a week, and I really did try hard to choose a default solution likely to break the least setups (certainly not pushed on a whim).

So, if you truly need 1.2 (which does surprise me), we'll have to make the support a NixOS option... or do you have any better suggestion?

[devhell]

@vcunat I'll reiterate: I'm not blaming anyone in particular, and certainly not blaming you. I'm just not sure if keeping wpa_supplicant 2.4 is the best option if this is to be included into the next stable release, which is due shortly. Some users which might be using stable will have a surprise waiting for them. This is my current concern really.

And yes, it surprised me too that it seems TLS 1.2 is needed here, but then again my university doesn't surprise me any more ;-)

[vcunat]

@devhell: the point is that before 2.4 there was no support for TLS 1.2 enabled by default, although it technically could be enabled IIRC (it's just we didn't have it in nixpkgs).

[devhell]

@vcunat I understand that. Granted, this sounds like a very ridiculous coincidence, but at the same time IT changed the configuration for our Eduroam infrastructure. I attended an "open" meeting today where they even discussed the new wireless roll-out. :-/

[devhell]

@vcunat Anyway, I don't wish to bother you any further with this. I'm not sure what the best solution might be though, sorry. So, as far as I'm concerned you can close this ticket since it seems no one else is running into an issue here. Thanks for taking the time to discuss it though! :-)

[vcunat]

I don't think this is a blocker anymore. AFAIK there doesn't exist a single (simple) config that would both allow TLS-1.2 and succeed with those broken radius versions (which seem still common).

[devhell]

This is no longer a problem for me either since Uni started to deploy an updated Eduroam.

[vcunat]

Hmm, I see the workaround was reverted, so what do we do about this to satisfy both cases? (Some want TLS-1.2 and some want eduroam.) Make it configurable? I can't see anyone having a version that can do both (e.g. Debian and Arch still use 2.3).

[vcunat]

I think there's a different problem in your case, notably not using a CA your machine recognizes:

TLS: Certificate verification failed, error 19 (self signed certificate in certificate chain) depth 3 for '/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root'

... but I'm no expert on these matters, and I do have some "AddTrust External Root" in my $SSL_CERT_FILE.

[ikervagyok]

i added this to my configuration, after installing cacert and downloading the root-certificate - without success

security.pki.certificateFiles = [ "${pkgs.cacert}/etc/ssl/certs/ca-bundle.crt" /AddTrustExternalCARoot.crt];

i also updated networkmanager and wpa-supplicant, still nothing. then i tried my old wpa_supplicant.conf[1] without networkmanager and it still couldn't connect. [2]

@vcunat any other hints?

[1] http://pastebin.com/rAjpnKQT
[2] http://pastebin.com/Vs57D0z1

[vcunat]

Yeah, in this log I see no certificate errors, but there's that wlp3s0: RSN: PMKID mismatch - authentication server may have derived different MSK?! which does seem to be the TLS-1.2 bug.

It's possible that commenting-out the config line in 783af9a isn't enough and =n has to be used instead. I can't see the default value for sure.

[vcunat]

BTW, I can't see anything relevant in changelog for the 2.5 bump #10114.

[ikervagyok]

i know, but i had to try the bump ;)

i have tried to explicitly set CONFIG_TLSV12=n, still nothing... but the line wlp3s0: RSN: PMKID mismatch - authentication server may have derived different MSK?! disappeared.

see: http://pastebin.com/L5FGaqJb

[devhell]

@ikervagyok Can you be certain that it's not a hardware/driver issue? In your pastebin the disconnect reason 3 is given.

[ikervagyok]

@devhell i really can't tell - i just know it works with debian/arch and it worked long time ago with nixos.
still, thanks to all of you helping out :)

[ikervagyok]

well, after upgrading wpa_supplicant didn't help, downgrading it to v2.3 did help (without relying on networkmanager for the time being)
i'm going to look through the wpa_supplicant changes between 2.3 and 2.4, but the 127k lines (git diff hostap_2_3..hostap_2_4 | wc -l) are not very inviting.

[vcunat]

You changed just the version and hash, right? (Not e.g. older version of whole nixpkgs.)

[ikervagyok]

@vcunat i did git checkout 299abee pkgs/os-specific/linux/wpa_supplicant/default.nix on the current master and rebuilt nixos.

[vcunat]

Hmm, there's such a big change in the config that it might be affected also by some of the other switches.

[ikervagyok]

@vcunat i am playing with those switches, let's see where it gets me - thanks for the hint

[ikervagyok]

my university had a radius-server update, still nothing... because the semerster has started, i have no time to debug this now, but i'll play around with it every now and then..

btw: i looked up the wpa-supplicant version for most other big distros - only gentoo uses 2.4 by default (and the fedora master branch) - all others stick with 2.3 or earlier, so maybe there is a much bigger issue at hand and i'll just have to sit it out.

[globin]

I can confirm that eduroam works with our wpa_supplicant 2.5.
Redacted config:

network={
    ssid="eduroam"
    key_mgmt=WPA-EAP
    eap=TTLS
    identity="[email protected]"
    subject_match="radius.lrz.de"
    anonymous_identity="[email protected]"
    password="XXXXX"
    ca_cert="/etc/ssl/certs/dtag_root.crt"
    phase2="auth=PAP"
}

See here for the configuration:
https://www.lrz.de/services/netz/mobil/802_1x/802_1x-linux/

(Actually should prefer PEAP/MSCHAPv2 but something needs to be enabled at compile time and haven't had time to debug so far)

[vcunat]

I don't think this issue is linked to eduroam (directly). Notably, each university provides their own authentication...

[ikervagyok]

ok, i don't know what happened, but now it just works.. either you lot fixed it, or my university did something.
thanks for all your help, it was (and still is) very much appreciated.

cheers, iker

[vcunat]

OK. I'm closing for now, as noone else has complained recently AFAIK.

[nicklowe]

It may be a rather poor, short sighted decision to disable TLS 1.2 by default. All you are potentially doing is creating a different compatibility problem for the future when RADIUS servers start defaulting to disabling TLS 1.0 and TLS 1.1

As Android 6.0 released with TLS 1.2 enabled by default, the compatibility issue is very quickly being mopped up server side.

[vcunat]

It's a short-term work around the broken radius installed on many places. I expect that to be all fixed in a few months or sooner.

[nicklowe]

Thanks, as long as it is short term with a deadline, that makes sense. My concern was that it could easily become forgotten about, being out of sight and out of mind, until RADIUS servers decide to prohibit TLS 1.0 and TLS 1.1

[vcunat]

It can be forgotten, but when it becomes to bother people, they should report it.

[nicklowe]

You really ought to actually revert this now for future releases as Google have already shipped Android 6.0 with this behaviour.

[vcunat]

Android is of no concern here, IMHO. It's the server behaviour that matters (that's what nixoses are interacting with).

[nicklowe]

You have completely missed the point ;)

Android 6.0 is forcing broken servers to get patched because devices running it cannot get a usable association to affected wireless networks. Because Google have already done that, it is now relatively safe and, on balance, reasonable for other clients to use TLS 1.2 by default.

Google took the compatibility hit on the chin.

[vcunat]

You have completely missed the point ;)

I see now. Still, it doesn't really force us; it forces WiFi providers to fix their radius, but it should enable us to change the default config soon. I'd rather wait a while from what I know now.

[nicklowe]

Yes, it definitely doesn't force you to do anything. I just meant that disabling TLS 1.2 by default is poor practice and likely unnecessary now as 'all the ducks are in a row'.

[kamilchm]

I'm facing the same problem now.
Commenting or settting n to CONFIG_TLSV12 doesn't work.

Downgrading wpa_supplicant to 2.3 makes the trick.