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
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
|
Details
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-PROPOSED-METHOD vendor=0 method=25 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: https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/969343 I also tracked down a similar Arch Forums post: https://bbs.archlinux.org/viewtopic.php?id=138103 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
https://gist.github.com/2314974
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.
plus OpenVPN doesn't work - SSL handshake timeout
https://bugs.launchpad.net/ubuntu/+source/wpasupplicant/+bug/969343
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 @@
#ifdef SSL_OP_NO_COMPRESSION
options |= SSL_OP_NO_COMPRESSION;
#endif /* SSL_OP_NO_COMPRESSION */
+ options |= SSL_OP_NO_TICKET;
SSL_set_options(conn->ssl, options);
conn->ssl_in = BIO_new(BIO_s_mem());
It links to various tickets including those filed with openssl and wpa_supplicant.
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]
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.
- Visit copy/paste or download this patch: http://w1.fi/bugz/attachment.cgi?id=235
- 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).
(I forgot to IgnorePkg wpa_supplicant, so I didn't even notice the update!)
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.