OpenSSL 1.0.1 is broken (AES-CBC issue)

Darkimmortal · 2012-03-29 20:23:32

Pierre wrote:

I have built openssl with the proposed workaround. I did some basic tests and it seems to work. Here are some packages for you guys to check out:
x86_64:
pacman -U https://users.archlinux.de/~pierre/tmp/openssl-1.0.1-2-x86_64.pkg.tar.xz

i686:
pacman -U https://users.archlinux.de/~pierre/tmp/openssl-1.0.1-2-i686.pkg.tar.xz
Let me know if these fix your issues (and wont break other things); I'll put them into [testing] then.

Seems to work perfectly for my needs

Edit: Or not, see below..

Last edited by Darkimmortal (2012-03-30 13:46:23)

loafer · 2012-03-29 20:29:07

It works here too. Thanks.

Pierre · 2012-03-30 08:28:53

So, a bunch of people tested this workaround and it seems simple enough to me. The package is now in [testing]. Thanks to shenson for the quick solution.

Søkka · 2012-03-30 13:13:57

For me it solved the problem with my Facebook app partially, I'm able to access https://graph.facebook.com/ again via links/curl/wget. But in PHP it still turns up with errors, could someone apply the patch to the php-openssl module as well?

Darkimmortal · 2012-03-30 13:39:42

Søkka wrote:

For me it solved the problem with my Facebook app partially, I'm able to access https://graph.facebook.com/ again via links/curl/wget. But in PHP it still turns up with errors, could someone apply the patch to the php-openssl module as well?

I've noticed this as well - easily reproducible with:

php -r "var_dump(fsockopen('ssl://graph.facebook.com',443,\$errnum,\$errstr,5));"

which produces:

Warning: fsockopen(): SSL: crypto enabling timeout in Command line code on line 1
Warning: fsockopen(): Failed to enable crypto in Command line code on line 1
Warning: fsockopen(): unable to connect to ssl://graph.facebook.com:443 (Unknown error) in Command line code on line 1
bool(false)

Last edited by Darkimmortal (2012-03-30 13:39:51)

EdgarButan · 2012-03-31 17:54:06

Is there any difference between the package in testing and the one from your "repo", Pierre?
The one from your repo does not seem to have helped.

Pierre · 2012-03-31 18:00:55

The package in core and from my repo are the same. If that did not help you probably have another issue.

EdgarButan · 2012-03-31 18:29:17

Hm, the symptoms fit, it started at about the same time…
Is there anything I can do wrong with installing the package?
I installed it (and just checked, the correct package is installed), rebooted, still slow.
No additional measures have to be taken, right?

djraymondnm · 2012-03-31 20:45:53

Check out Debian bug 658276 at www.debian.org/Bugs/ regarding curl and ssl. Could this have something to do with the reported ssl problems?

extofme · 2012-04-01 08:40:22

thanks for update (looks to be in [core] now, yes?) ... unfortunately i'm still getting the same prob:

# time curl https://api-aa-3t.paypal.com/2.0/
curl: (35) Unknown SSL protocol error in connection to api-aa-3t.paypal.com:443 

real	1m0.159s
user	0m0.017s
sys	0m0.000s

# pacman -Q openssl
openssl 1.0.1-2

# ldd `which curl` |grep ssl
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f8e6019c000)

# pacman -Qo /usr/lib/libssl.so.1.0.0
/usr/lib/libssl.so.1.0.0 is owned by openssl 1.0.1-2

# curl -s https://www.google.com |wc -c
13417

... getting this on 1 laptops, 1 server, and 3 VMS -- more-or-less across the board for me. all x86_64.

what else we got?

Last edited by extofme (2012-04-01 08:58:22)

Søkka · 2012-04-01 21:05:13

Yeh, curl still seems to be affected.

# curl https://graph.facebook.com/platform
curl: (35) Unknown SSL protocol error in connection to graph.facebook.com:443

For example. Wget & Links work, didn't work previously. The package in core is indeed the same, didn't update when I executed 'pacman -Syu'.

extofme wrote:

thanks for update (looks to be in [core] now, yes?) ... unfortunately i'm still getting the same prob:
# time curl https://api-aa-3t.paypal.com/2.0/
curl: (35) Unknown SSL protocol error in connection to api-aa-3t.paypal.com:443 

real	1m0.159s
user	0m0.017s
sys	0m0.000s

# pacman -Q openssl
openssl 1.0.1-2

# ldd `which curl` |grep ssl
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f8e6019c000)

# pacman -Qo /usr/lib/libssl.so.1.0.0
/usr/lib/libssl.so.1.0.0 is owned by openssl 1.0.1-2

# curl -s https://www.google.com |wc -c
13417
... getting this on 1 laptops, 1 server, and 3 VMS -- more-or-less across the board for me. all x86_64.
what else we got?

extofme · 2012-04-01 22:35:13

as stated in the referenced openssl bug, it definitely is related to the hello/handshake size:

# diff -u www.paypal.com.ssl-hello www.google.com.ssl-hello 
--- www.paypal.com.ssl-hello	2012-04-01 12:43:57.966419738 -0500
+++ www.google.com.ssl-hello	2012-04-01 12:44:24.872386254 -0500
@@ -1,7 +1,7 @@
 write to 0x6b0180 [0x6b0200] (263 bytes => 263 (0x107))
-0000 - 16 03 02 01 02 01 00 00-fe 03 02 4f 78 92 fc 53   ...........Ox..S
-0010 - b3 90 91 39 31 84 39 b7-aa 29 9d e0 3f e2 b3 a2   ...91.9..)..?...
-0020 - b1 0c ef e5 94 13 68 66-e5 05 92 00 00 74 c0 14   ......hf.....t..
+0000 - 16 03 02 01 02 01 00 00-fe 03 02 4f 78 93 09 ec   ...........Ox...
+0010 - 2e e4 db b9 75 15 c3 54-7c 98 65 0f ab 28 27 40   ....u..T|.e..('@
+0020 - ef 76 1d e0 02 8c b4 a8-55 af 2d 00 00 74 c0 14   .v......U.-..t..
 0030 - c0 0a c0 22 c0 21 00 6b-00 6a 00 39 00 38 00 88   ...".!.k.j.9.8..
 0040 - 00 87 c0 0f c0 05 00 3d-00 35 00 84 c0 12 c0 08   .......=.5......
 0050 - c0 1c c0 1b 00 16 00 13-c0 0d c0 03 00 0a c0 13   ................
@@ -10,7 +10,7 @@
 0080 - 00 41 00 07 c0 11 c0 07-c0 0c c0 02 00 05 00 04   .A..............
 0090 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03   ................
 00a0 - 00 ff 02 01 00 00 60 00-00 00 13 00 11 00 00 0e   ......`.........
-00b0 - 77 77 77 2e 70 61 79 70-61 6c 2e 63 6f 6d 00 0b   www.paypal.com..
+00b0 - 77 77 77 2e 67 6f 6f 67-6c 65 2e 63 6f 6d 00 0b   www.google.com..
 00c0 - 00 04 03 00 01 02 00 0a-00 34 00 32 00 0e 00 0d   .........4.2....
 00d0 - 00 19 00 0b 00 0c 00 18-00 09 00 0a 00 16 00 17   ................
 00e0 - 00 08 00 06 00 07 00 14-00 15 00 04 00 05 00 12   ................

... above is the diff of the hello/handshake with www.paypal.com and www.google.com respectively, chosen because they have identical size (266 bytes under curl) -- google succeeds, regardless of hello length, and paypal fails until the complete length is under 255 bytes, and thus representable by a single byte (0xFF). the hello is identical (save the 16 bytes or so of random-ness) the moment the size requires 2 bytes (0x01 0x02 in this case) paypal fails, even though two bytes are allocated for this purpose (and 3 bytes in the record header, not sure the semantics of each) ...

very odd. note that bbs.archlinux.org, www.googlemail.com, and several others exceeding 255 bytes work just fine.

both servers report only TLS1.0 support, not 1.1 or 1.2.

examples:

# openssl s_client -debug -connect www.paypal.com:443 -servername www.paypal.com
^^^^ hangs [263 bytes] (SNI extension)

# openssl s_client -debug -connect www.paypal.com:443
^^^^ works [240 bytes]

# curl --trace - https://secure.paypal.com
^^^^ hangs [257 bytes]

# curl --trace - https://www.paypal.com
^^^^ works [254 bytes]

Last edited by extofme (2012-04-02 00:28:59)

jwhendy · 2012-04-04 21:25:02

I started being unable to access my company WPA2 wireless recently and thought the issue might be related to openssl since wpa_supplicant failed due to an SSLv3 handshake fatal error. I used ARM to revert to openssl 1.0.0.h-1 and after trying all kinds of other things... it now works. Just thought I'd chime in here. Is this no the same issue?

My corporate wireless uses WPA2 PEAP-GTC and does use AES encryption.

extofme · 2012-04-04 21:34:45

jwhendy wrote:

I started being unable to access my company WPA2 wireless recently and thought the issue might be related to openssl since wpa_supplicant failed due to an SSLv3 handshake fatal error. I used ARM to revert to openssl 1.0.0.h-1 and after trying all kinds of other things... it now works. Just thought I'd chime in here. Is this no the same issue?
My corporate wireless uses WPA2 PEAP-GTC and does use AES encryption.

sure sounds like it ... i too used ARM to rollback to 2012/03/20 (last day of 1.0.0h), and haven't moved since.

is no one else affected by this??? openssl is one of those things that "absolutely must work perfectly else we should hold the upgrade."

i mean stuff has been stalled for video drivers and what not ... this is huge problem for me, and the first time i've ever needed to halt updates to 5+ machines in ~3 years of using Arch ...

very :-(

edit: and in fairness, the problem may not eve be openssl (feels like bad proprietary SSL impl to me ... older openssl seems to work fine, and so does google and others), but IMO it should be stalled until we know for sure ...

... or am i doing something wrong here? i am still unable to access the aforementioned sites using curl, or any other tool.

Last edited by extofme (2012-04-04 21:37:51)

jwhendy · 2012-04-05 03:09:55

@extofme: I was surprised to not find more myself. I originally thought my corporate wireless changed their protocols or something. I did quite a bit of digging to make sure it wasn't me. It wasn't until I saw the failed sslv3 handshake error that it occurred this might be the issue. Hardly any noise is going on about this that I've seen with my searches. I wonder why others aren't seeing this -- perhaps only certain encryption methods that are quasi-rare?

By the way... have you filed a bug report? If two of us have had things fixed via downgrading... that should be enough to support a bug report, right?

Lothium · 2012-04-05 08:26:47

For me, ssl-sites in rekonq and qupzilla are not working, but I can access my wlan.

jwhendy · 2012-04-05 23:08:14

Bug report created: https://bugs.archlinux.org/task/29301

extofme · 2012-04-05 23:45:03

i felt the need to paste this:

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.

dfelicia · 2012-04-07 23:29:11

I've noticed this as well - easily reproducible with:

php -r "var_dump(fsockopen('ssl://graph.facebook.com',443,\$errnum,\$errstr,5));"

which produces:

Warning: fsockopen(): SSL: crypto enabling timeout in Command line code on line 1
Warning: fsockopen(): Failed to enable crypto in Command line code on line 1
Warning: fsockopen(): unable to connect to ssl://graph.facebook.com:443 (Unknown error) in Command line code on line 1
bool(false)

Any workaround for this?

SoapSeller · 2012-04-09 20:58:03

This seems related.
https://github.com/emesene/emesene/issu … nt-4748393

both https://graph.facebook.com/platform & https://api-aa-3t.paypal.com/2.0/ seems to work with curl if I force SSLv3(-3/--sslv3).

Darkimmortal · 2012-04-17 15:08:30

Darkimmortal wrote:

Søkka wrote:
For me it solved the problem with my Facebook app partially, I'm able to access https://graph.facebook.com/ again via links/curl/wget. But in PHP it still turns up with errors, could someone apply the patch to the php-openssl module as well?
I've noticed this as well - easily reproducible with:
php -r "var_dump(fsockopen('ssl://graph.facebook.com',443,\$errnum,\$errstr,5));"
which produces:
Warning: fsockopen(): SSL: crypto enabling timeout in Command line code on line 1
Warning: fsockopen(): Failed to enable crypto in Command line code on line 1
Warning: fsockopen(): unable to connect to ssl://graph.facebook.com:443 (Unknown error) in Command line code on line 1
bool(false)

Still fails with openssl-1.0.1-3

Darkimmortal · 2012-04-19 15:47:53

Working perfectly now in openssl-1.0.1.a-1

extofme · 2012-04-19 19:32:08

Darkimmortal wrote:

Working perfectly now in openssl-1.0.1.a-1

hooray! looks to be the same here:

# openssl s_client -connect api-aa-3t.paypal.com:443 -servername api-aa-3t.paypal.com
[...]
SSL-Session:
    Protocol  : TLSv1
    Cipher    : DES-CBC3-SHA
[...]

# openssl s_client -connect graph.facebook.com:443 -servername graph.facebook.com
[...]
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
[...]

if i compare with the link i poseted previously:

https://gist.github.com/2314974

... the handshake size seems to have shrunk a bit; anything larger than 0x104 still hangs on these servers, but that requires a pretty large domain name (and use of SNI extension).

Arch Linux

#26 2012-03-29 20:23:32

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#27 2012-03-29 20:29:07

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#28 2012-03-30 08:28:53

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#29 2012-03-30 13:13:57

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#30 2012-03-30 13:39:42

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#31 2012-03-31 17:54:06

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#32 2012-03-31 18:00:55

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#33 2012-03-31 18:29:17

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#34 2012-03-31 20:45:53

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#35 2012-04-01 08:40:22

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#36 2012-04-01 21:05:13

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#37 2012-04-01 22:35:13

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#38 2012-04-04 21:25:02

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#39 2012-04-04 21:34:45

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#40 2012-04-05 03:09:55

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#41 2012-04-05 08:26:47

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#42 2012-04-05 23:08:14

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#43 2012-04-05 23:45:03

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#44 2012-04-07 23:29:11

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#45 2012-04-09 20:58:03

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#46 2012-04-17 15:08:30

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#47 2012-04-19 15:47:53

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

#48 2012-04-19 19:32:08

Re: OpenSSL 1.0.1 is broken (AES-CBC issue)

Board footer