FS#54390 - [wpa_supplicant] EAP-PEAP not working with openssl 1.1

Attached to Project: Arch Linux
Opened by Mauro Santos (R00KIE) - Friday, 09 June 2017, 16:34 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Friday, 10 August 2018, 14:04 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 6
Private No

Details

The version of wpa_supplicant currently in the repos (1:2.6-6) does not work with the eduroam connection I have access to. The connection is protected with EAP-PEAP without certificates.

The configuration I'm testing with is as follows:

ap_scan=1
p2p_disabled=1

network={
ssid="eduroam"
key_mgmt=WPA-EAP
eap=PEAP
identity="my_identity"
password="my_plaintext_password"
phase1="tls_disable_tlsv1_1=1 tls_disable_tlsv1_2=1"
phase2="auth=MSCHAPV2"
}


Linking wpa_supplicant against openssl 1.0 makes the connection work again without having to make any other changes.

I have inquired in upstream's mailing list[1] but until now I have received no further feedback than what was posted to the list. I have made reference to this problem is another bug report[2] and the commit message for the fix was "fix isues with EAP-PEAP authentication", however it was actually fixing a bug with encrypted certificates.


[1] http://lists.infradead.org/pipermail/hostap/2017-May/037633.html
[2] https://bugs.archlinux.org/task/54233
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Friday, 10 August 2018, 14:04 GMT
Reason for closing:  Not a bug
Comment by Bartłomiej Piotrowski (Barthalion) - Sunday, 18 June 2017, 22:05 GMT
Have you made any progress on this? I have access to such network at work but I don't really have time to debug it and I'm unwilling to stay "overhours".

I can just switch wpa_supplicant to openssl-1.0 too.
Comment by Mauro Santos (R00KIE) - Sunday, 18 June 2017, 23:08 GMT
I haven't received any more replies on hostap's mailing list, which for all I can tell is the only place to inquire/report problems (short of emailing someone directly - who to email I'm not sure). I have access to an EAP-PEAP protected network only once a week at university (when I go there) and soon it will be on holiday and mostly closed so I won't have much chance to also test this.

What I'm curious about is if the current version in the repos works fine for you at work. What I'm afraid is that in my case the problem could be related to some interaction with a broken server and we could be just wasting time chasing this since I have not seen anyone else complain in the forums that eduroam/wifi is not working.

For my usage I've compiled wpa_supplicant against openssl-1.0 and everything seems to work (eduroam with EAP-PEAP at uni and regular wpa2 at home). If doing any change maybe the safe approach is linking against openssl-1.0, or doing whatever other big distros do, my guess is link with openssl-1.0. That would at least ensure we are using what everyone else is using and thus should be well tested and if bugs are discovered there is a higher chance someone will provide a patch.

The readme for wpa_supplicant says:

Supported TLS/crypto libraries:
- OpenSSL (default)
- GnuTLS

.....

Optional libraries for EAP-TLS, EAP-PEAP, and EAP-TTLS:
- OpenSSL (tested with 1.0.1 and 1.0.2 versions; assumed to
work with most relatively recent versions; this is likely to be
available with most distributions, http://www.openssl.org/)
- GnuTLS
- internal TLSv1 implementation

I have no idea what kind of bugs may be lurking in the code if some less well tested code path is used, not to mention any possible security issues.
Comment by Bartłomiej Piotrowski (Barthalion) - Wednesday, 21 June 2017, 20:31 GMT
I haven't noticed it as I rarely move with my laptop around the office, so I use Ethernet most of the time anyway.

Fedora 25 links wpa_supplicant with the old OpenSSL; I e-mailed Pierre about moving it to [core] so I can rebuild wpa_supplicant.
Comment by anonymous (Austaras) - Friday, 29 June 2018, 06:21 GMT
  • Field changed: Percent Complete (100% → 0%)
fedora has already land a patch and fix this issue
source:
https://src.fedoraproject.org/cgit/rpms/wpa_supplicant.git/commit/?h=f28&id=3060fdc1de27c1b9603503d2443839158336779c
https://bugzilla.redhat.com/show_bug.cgi?id=1465138
Comment by Eli Schwartz (eschwartz) - Friday, 29 June 2018, 06:27 GMT
This and  FS#54233  were both related to wpa_supplicant not working great with openssl 1.1, looks like that fedora bug was for the other one.

...

As per  FS#59171  is it time to revisit building against openssl 1.1? Hopefully a year later it would work, and seemingly does work for Fedora (since they've defaulted to this)...
Comment by Bartłomiej Piotrowski (Barthalion) - Friday, 29 June 2018, 06:52 GMT
It's more complicated. EAP-PEAP of course works (and if you look at svn history, we had a version built against OpenSSL 1.1 in testing for a while). Now, our OpenSSL simply disables older, "insecure" ciphers during compilation, that unfortunately are still used for certificates in many companies and universities. We could either enable it, but I consider it a worse idea than sticking to 1.0; manage cipher suite on runtime like Fedora does, which is overcomplicated and opaque or break WiFi for some users. Thus, we're going to use 1.0 for a while yet, especially when it is still needed by other packages.

Loading...