Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#29301 - [openssl] 1.0.1 update breaks WPA2 and curl functionality

Attached to Project: Arch Linux
Opened by John Henderson (jwhendy) - Thursday, 05 April 2012, 23:03 GMT
Last edited by Pierre Schmitz (Pierre) - Monday, 25 February 2013, 15:48 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No


Description: The ability to connect to my corporate WPA2 wireless ceased recently. In tracking various logs, here is the pertinent information:

-- /var/log/wicd/wicd.log reported my last successful wireless connection was 03/18/2012

-- /var/lib/wicd/configurations digging confirmed that the wpa_supplicant script used on 03/05/2012 was identical to 03/30/2012 when I was getting failures in wicd due to a bad password

-- Running wpa_supplicant manually gave the following error:

Associated with 00:15:c6:29:01:50
CTRL-EVENT-EAP-STARTED EAP authentication started
CTRL-EVENT-EAP-METHOD EAP vendor 0 method 25 (PEAP) selected
SSL: SSL3 alert: read (remote end reported an error):fatal:bad certificate
OpenSSL: openssl_handshake - SSL_connect error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate
CTRL-EVENT-EAP-FAILURE EAP authentication failed

This had me checking for pacman updates since my last successful wireless connection. dhcpcd and openssl were candidates. In searching for openssl issues (especially from the bad SSL3 certificate error above), I found an Ubuntu bug that was very similar:

I also tracked down a similar Arch Forums post:

My corporate wireless uses PEAP+GTC, which uses AES, so this seemed relevant. I used Arch Rollback Machine to downgrade openssl from 1.0.1-2 to 1.0.0.h-1 and successfully connected to wireless again.

Steps to reproduce:
-- Update to openssl-1.0.1-2
-- Try to connect to PEAP-GTC WPA2 enterprise network that uses AES as an authentication protocol
-- Repeat as desired

The Arch forum reports interference with curl, ssh, and PuTTY, so I include those issues as well. Downgrading to 1.0.0.h-1 has been successful for several users per the Arch forum thread above.
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Monday, 25 February 2013, 15:48 GMT
Reason for closing:  Fixed
Comment by John Henderson (jwhendy) - Thursday, 05 April 2012, 23:06 GMT
There may be a better title for this in retrospect. Some of the other users with more network experience could suggest more proper descriptions, like a specific nomenclature for the exact protocol(s) that is/are affected.
Comment by C Anthony Risinger (extofme) - Thursday, 05 April 2012, 23:44 GMT
i felt the need to paste this:

that normally fails for me every single time ... but somehow this one succeeded. prior to this i had ran the same command several times without the `-servername` arg (ie. it was succeeding). it the worked ONE time; all subsequent attempts failed.

notice how the header is GREATER than 255 bytes (the only thing that seems to cause consistent failure) ...

... maybe someone can see why ... i couldn't.
Comment by oleg (oleg-a) - Saturday, 07 April 2012, 11:56 GMT
Having the same problem with openssl 1.0.1-2. Curl gives same error as on

plus OpenVPN doesn't work - SSL handshake timeout
Comment by John Henderson (jwhendy) - Tuesday, 17 April 2012, 23:11 GMT
The recent update to 1.0.1-3 did not fix this for me.
Comment by Reed Lipman (rlipman) - Thursday, 19 April 2012, 16:03 GMT
I was getting timeouts when attempting to curl the Facebook API with openssl 1.0.1-2. Upgrading to 1.0.1.a-1 fixed it for me.
Comment by John Henderson (jwhendy) - Thursday, 19 April 2012, 20:45 GMT
Did *not* fix connecting to WPA2 (GTC + PEAP, AES auth) for me.
Comment by Pierre Schmitz (Pierre) - Friday, 20 April 2012, 10:55 GMT
Did you report this issue upstream? This is most likely not a packaging issue here and I cannot help you here.
Comment by John Henderson (jwhendy) - Friday, 20 April 2012, 15:23 GMT
I haven't, but will figure out how to do that today or this weekend.
Comment by Alb (pzdmrd) - Wednesday, 20 June 2012, 13:21 GMT
It looks like the openssl update affected the wpa_supplicant behaviour:

applying the one single line patch to wpa_supplicant 0.7.3-5 and rebuilding with ABS,
fixed the problem for me.

the patch for wpa_supplicant is incredibly simple, but for me it did the trick:

diff -ru a/src/crypto/tls_openssl.c b/src/crypto/tls_openssl.c
--- a/src/crypto/tls_openssl.c 2012-06-06 18:11:00.976524984 -0600
+++ b/src/crypto/tls_openssl.c 2012-06-06 18:10:58.240540303 -0600
@@ -917,6 +917,7 @@
+ options |= SSL_OP_NO_TICKET;
SSL_set_options(conn->ssl, options);

conn->ssl_in = BIO_new(BIO_s_mem());

Comment by Eric Donkersloot (lordchaos) - Monday, 23 July 2012, 20:20 GMT
This is apparently still an issue with wpa_supplicant 1.0-1 ?
Comment by John Henderson (jwhendy) - Monday, 23 July 2012, 20:26 GMT
The same bug at Ubuntu seems to be a better place to track things...

It links to various tickets including those filed with openssl and wpa_supplicant.
Comment by John Henderson (jwhendy) - Thursday, 06 September 2012, 16:59 GMT
The patch here works for me:

It's the same as mentioned by @pzdmrd above, though copying/pasting his didn't work, presumably due to line break/spacing preservation from html vs. the raw patch itself. I'm inexperienced with patches; for others this might have been trivial, but I had to hunt around for a properly formatted version. Patched by putting it into ~/abs/wpa_supplicant/src/wpa_supplicant-1.0/ and then adding this to PKGBUILD: [code]patch -p1 -i "$srcdir/wpa_supplicant-1.0/openssl.patch"[/code]
Comment by Eric Donkersloot (lordchaos) - Thursday, 18 October 2012, 11:36 GMT
I still get the "fatal: bad certificate" error with wpa_supplicant 1.0-2. On Android (4.1.2), wpa_supplicant has been successfully patched.
Should this bug not be assigned to wpa_supplicant instead?
I know it may not be a bug in either wpa_supplicant or openssl, technically speaking, but I guess this is affecting quite a few users out there.
Comment by John Henderson (jwhendy) - Friday, 26 October 2012, 18:00 GMT
@Eric: At least for me, the patch in my post directly above yours worked for 1.0-1 and 1.0-2. I just upgraded from 1.0-1 -> 1.0-2 yesterday and wireless broke again (with Arch's vanilla wpa_supplicant package). Using ABS, I applied the same patch to 1.0-2 and everything works fine. For clarification:

- Visit copy/paste or download this patch:
- Update abs by running "sudo abs"
- Copy wpa_supplicant: "cp -r /var/abs/core/wpa_supplicant /your/build/dir/"
- CD to the abs dir: "cd /your/build/dir/wpa_supplicant"
- Download the source only: "makepkg -o"
- Copy the patch to the right place: "cp /path/to/file.patch src/wpa_supplicant-1.0/"
- Edit the PKGBUILD to contain "patch -p1 -i "$srcdir/wpa_supplicant-1.0/openssl.patch"" (you need the quotations around the path portion of that)
--- I put mine after the line "patch patch -Np1 -i "$srcdir/hostap_allow-linking-with-libnl-3.2.patch""
- Make/install the package: "makepkg -si"

Should work immediately (no need to reboot).
Comment by Eric Donkersloot (lordchaos) - Friday, 26 October 2012, 18:53 GMT
@John: thank you very much for the mini tutorial. I am aware I can patch the source and create my own package, but that's not my point to be honest. Let me rephrase my question: is it Arch's policy to ship the vanilla version of wpa_supplicant only?
Comment by John Henderson (jwhendy) - Friday, 26 October 2012, 18:58 GMT
@Eric: No problem, and thanks for the clarification. Ah, so you were making the point that Android has patched their version of wpa_supplicant as a way of wondering if Arch could make an alternative package? Perhaps the best alternative would be to put together a modified version on AUR which includes this patch and stays up to date with the Arch vanilla release until a "real" fix is found? Frankly, *my* point of curiosity is why in the world this obviously huge issue (wireless is a pretty big deal) is still going on 6mos after the problem has been made extremely well known and reported on several distros, with openssl and with wpa_supplicant!?
Comment by Eric Donkersloot (lordchaos) - Friday, 26 October 2012, 19:00 GMT
@John: +1
Comment by Eric Donkersloot (lordchaos) - Wednesday, 23 January 2013, 09:55 GMT
Has anybody tested yet with the wpa_supplicant (2.0-1) package from testing?
Comment by Jing Wang (jingwang) - Monday, 11 February 2013, 01:09 GMT
wpa_supplicant 2.0-1 seems to fix this for me.

(I forgot to IgnorePkg wpa_supplicant, so I didn't even notice the update!)
Comment by Eric Donkersloot (lordchaos) - Monday, 11 February 2013, 06:09 GMT
Yes, I haven't had to build my own version of wpa_supplicant this time so the update seems to have fixed the issue.
Comment by Alb (pzdmrd) - Monday, 11 February 2013, 14:58 GMT
wpa_supplicant 2.0-1 fixes the problem for me as well.

It worths to mention the new wpa_supplicant.conf has a comment stating:

# tls_disable_session_ticket=1 - disable TLS Session Ticket extension
# tls_disable_session_ticket=0 - allow TLS Session Ticket extension to be used
# Note: If not set, this is automatically set to 1 for EAP-TLS/PEAP/TTLS
# as a workaround for broken authentication server implementations unless
# EAP workarounds are disabled with eap_workarounds=0.
Comment by Pierre Schmitz (Pierre) - Sunday, 17 February 2013, 10:54 GMT
Can you confirm that this still works with openssl-1.0.1.e-2? Can we close this bug?
Comment by Jing Wang (jingwang) - Sunday, 17 February 2013, 21:56 GMT
Still works for me with openssl-1.0.1.e-3. Closing seems reasonable.
Comment by Alb (pzdmrd) - Monday, 18 February 2013, 10:47 GMT
I confirm wpa_supplicant 2.0.1 with openssl-1.0.1.e-3 is working for me
Comment by Eric Donkersloot (lordchaos) - Monday, 25 February 2013, 10:52 GMT
I also confirm everything is working fine using openssl 1.0.1.e-3 & wpa_supplicant 2.0-2. This bug can be closed as far as I am concerned.