FS#33919 - [openssl] 1.0.1.e-3 broken (curl)

Attached to Project: Arch Linux
Opened by Brandon (hashstat) - Monday, 18 February 2013, 17:42 GMT
Last edited by Pierre Schmitz (Pierre) - Saturday, 02 November 2013, 20:41 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

Details

Description:

Attempting to run aurget this morning, after a system update, produced SSL errors from curl. So I tried connecting directly with the openssl s_client command:

$ openssl s_client -connect aur.archlinux.org:443
CONNECTED(00000003)
139782028748456:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:177:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 322 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

Downgrading to openssl 1.0.1.c-1 (which is the previous version I was using) fixes the problem.

Additional info:
* openssl 1.0.1.e-3
* related to  FS#33914 

Steps to reproduce:

Install openssl-1.0.1.e-3 and attempt an SSL connection (using curl or another tool wich uses openssl) to aur.archlinux.org:443.
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Saturday, 02 November 2013, 20:41 GMT
Reason for closing:  Not a bug
Comment by Pierre Schmitz (Pierre) - Wednesday, 20 February 2013, 16:40 GMT
This works fine for me.
Comment by Brandon (hashstat) - Friday, 22 February 2013, 04:21 GMT
I tried this on my home computer and it works fine. Perhaps it has something to do with my companies firewall. I'll look into it deeper.
Comment by Brandon (hashstat) - Friday, 22 February 2013, 18:27 GMT
I'm checking with my network team to determine if the firewall has anything to do with it, but I'm not sure what will come of that. Playing around with openssl some more, I am only able to reproduce the error against 78.46.78.247, the bug, wiki, and aur server. I can connect okay if I use the -no_tls1 flag, which forces an SSL3 connection. But TLS just doesn't work. I get disconnected right after the "Client Hello" is ACK'd.
Comment by william douglas (wdouglas) - Tuesday, 26 February 2013, 22:45 GMT
I see a similar problem, 1.0.1.c-1 was works but if I upgrade to .e-3 then I get an SSL connection error (connection reset by peer). I actually don't get any response (other than timeout, just sits in connect()) trying to use openssl s_client though I'm guessing that's because it doesn't look at any proxy settings as far as I can tell from the strace. My work has a proxy that could be a reason for the problem not being apparent to everyone.
Comment by Olivier Langlois (lano1106) - Thursday, 28 February 2013, 22:27 GMT
I am having the same problem. That is curl is sending the TLS ClientHello msg and the server is resetting the TCP connection without any explanation or replying.

with curl --trace and a small ClientHello msg parser, I haven't been able to notice anything suspicious except that the DEFLATE compression method is missing with 1.0.1.e-3.

In the attachement, you have my parser program, a program that convert the ClientHello msg from curl trace file to bin, badcurl.txt|bin from openssl 1.0.1.e-3. goodcurl (from Ubuntu VM that works from same network)

Parsing output:

lano1106@hpmini ~/dev/text_manip $ ./hello_parse badcurl.bin
length: 334
msg type: ClientHello
Protocol version: 3.3
Random:
time: Wed Feb 27 13:15:59 2013
random bytes: 3c685458dfcd97d02491f2f4f0bfc77a7777695bbe4a9dc6f69dd079
Session id: empty
Cypher suites : 80 suites
c030 ECDHE_RSA_WITH_AES_256_GCM_SHA384
c02c ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
c028 ECDHE_RSA_WITH_AES_256_CBC_SHA384
c024 ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
c014 ECDHE_RSA_WITH_AES_256_CBC_SHA
c00a ECDHE_ECDSA_WITH_AES_256_CBC_SHA
c022 SRP_SHA_DSS_WITH_AES_256_CBC_SHA
c021 SRP_SHA_RSA_WITH_AES_256_CBC_SHA
00a3 DHE_DSS_WITH_AES_256_GCM_SHA384
009f DHE_RSA_WITH_AES_256_GCM_SHA384
006b DHE_RSA_WITH_AES_256_CBC_SHA256
006a DHE_DSS_WITH_AES_256_CBC_SHA256
0039 DHE_RSA_WITH_AES_256_CBC_SHA
0038 DHE_DSS_WITH_AES_256_CBC_SHA
0088 DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
0087 DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
c032 ECDH_RSA_WITH_AES_256_GCM_SHA384
c02e ECDH_ECDSA_WITH_AES_256_GCM_SHA384
c02a ECDH_RSA_WITH_AES_256_CBC_SHA384
c026 ECDH_ECDSA_WITH_AES_256_CBC_SHA384
c00f ECDH_RSA_WITH_AES_256_CBC_SHA
c005 ECDH_ECDSA_WITH_AES_256_CBC_SHA
009d RSA_WITH_AES_256_GCM_SHA384
003d RSA_WITH_AES_256_CBC_SHA256
0035 RSA_WITH_AES_256_CBC_SHA
0084 RSA_WITH_CAMELLIA_256_CBC_SHA
c012 ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
c008 ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
c01c SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA
c01b SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
0016 DHE_RSA_WITH_3DES_EDE_CBC_SHA
0013 DHE_DSS_WITH_3DES_EDE_CBC_SHA
c00d ECDH_RSA_WITH_3DES_EDE_CBC_SHA
c003 ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
000a RSA_WITH_3DES_EDE_CBC_SHA
c02f ECDHE_RSA_WITH_AES_128_GCM_SHA256
c02b ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
c027 ECDHE_RSA_WITH_AES_128_CBC_SHA256
c023 ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
c013 ECDHE_RSA_WITH_AES_128_CBC_SHA
c009 ECDHE_ECDSA_WITH_AES_128_CBC_SHA
c01f SRP_SHA_DSS_WITH_AES_128_CBC_SHA
c01e SRP_SHA_RSA_WITH_AES_128_CBC_SHA
00a2 DHE_DSS_WITH_AES_128_GCM_SHA256
009e DHE_RSA_WITH_AES_128_GCM_SHA256
0067 DHE_RSA_WITH_AES_128_CBC_SHA256
0040 DHE_DSS_WITH_AES_128_CBC_SHA256
0033 DHE_RSA_WITH_AES_128_CBC_SHA
0032 DHE_DSS_WITH_AES_128_CBC_SHA
009a DHE_RSA_WITH_SEED_CBC_SHA
0099 DHE_DSS_WITH_SEED_CBC_SHA
0045 DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
0044 DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
c031 ECDH_RSA_WITH_AES_128_GCM_SHA256
c02d ECDH_ECDSA_WITH_AES_128_GCM_SHA256
c029 ECDH_RSA_WITH_AES_128_CBC_SHA256
c025 ECDH_ECDSA_WITH_AES_128_CBC_SHA256
c00e ECDH_RSA_WITH_AES_128_CBC_SHA
c004 ECDH_ECDSA_WITH_AES_128_CBC_SHA
009c RSA_WITH_AES_128_GCM_SHA256
003c RSA_WITH_AES_128_CBC_SHA256
002f RSA_WITH_AES_128_CBC_SHA
0096 RSA_WITH_SEED_CBC_SHA
0041 RSA_WITH_CAMELLIA_128_CBC_SHA
0007 RSA_WITH_IDEA_CBC_SHA
c011 ECDHE_RSA_WITH_RC4_128_SHA
c007 ECDHE_ECDSA_WITH_RC4_128_SHA
c00c ECDH_RSA_WITH_RC4_128_SHA
c002 ECDH_ECDSA_WITH_RC4_128_SHA
0005 RSA_WITH_RC4_128_SHA
0004 RSA_WITH_RC4_128_MD5
0015 DHE_RSA_WITH_DES_CBC_SHA
0012 DHE_DSS_WITH_DES_CBC_SHA
0009 RSA_WITH_DES_CBC_SHA
0014 DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
0011 DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
0008 RSA_EXPORT_WITH_DES40_CBC_SHA
0006 RSA_EXPORT_WITH_RC2_CBC_40_MD5
0003 RSA_EXPORT_WITH_RC4_40_MD5
00ff EMPTY_RENEGOTIATION_INFO_SCSV
compression method : 1 method
0 null
Hello Extensions: len 133 remLen 133
(0) server_name : aur.archlinux.org
(11) Supported Point Formats:
uncompressed (0)
ansiX962_compressed_prime (1)
ansiX962_compressed_char2 (2)
(10) Elliptic curves:
sect571r1 (14)
sect571k1 (13)
secp521r1 (25)
sect409k1 (11)
sect409r1 (12)
secp384r1 (24)
sect283k1 (9)
sect283r1 (10)
secp256k1 (22)
secp256r1 (23)
sect239k1 (8)
sect233k1 (6)
sect233r1 (7)
secp224k1 (20)
secp224r1 (21)
sect193r1 (4)
sect193r2 (5)
secp192k1 (18)
secp192r1 (19)
sect163k1 (1)
sect163r1 (2)
sect163r2 (3)
secp160k1 (15)
secp160r1 (16)
secp160r2 (17)
(13) Signature Algorithms:
sha512 (6), rsa (1)
sha512 (6), dsa (2)
sha512 (6), ecdsa (3)
sha384 (5), rsa (1)
sha384 (5), dsa (2)
sha384 (5), ecdsa (3)
sha256 (4), rsa (1)
sha256 (4), dsa (2)
sha256 (4), ecdsa (3)
sha224 (3), rsa (1)
sha224 (3), dsa (2)
sha224 (3), ecdsa (3)
sha1 (2), rsa (1)
sha1 (2), dsa (2)
sha1 (2), ecdsa (3)
md5 (1), rsa (1)
(15) heartbeat mode: peer_allowed_to_send(1)
Comment by Olivier Langlois (lano1106) - Thursday, 28 February 2013, 22:49 GMT
I should add that this is architecture independent problem. I do have the problem with i686.
Comment by Olivier Langlois (lano1106) - Thursday, 28 February 2013, 23:05 GMT
Just run my parser with openssl-1.0.1.d-1 which connects fine to aur.archlinux.org. Still not DEFLATE compression but the difference with 1.0.1.e-3 is the protocol version.

The server just refuse ClientHello v3.3!

lano1106@hpmini ~/dev/text_manip $ ./hello_parse openssl-1.0.1.d-1.bin
length: 240
msg type: ClientHello
Protocol version: 3.2
Random:
time: Thu Feb 28 17:57:12 2013
random bytes: 250eb25d370e69dd86232c91c17261f861ef20e7372623d71d0313d9
Session id: empty
Cypher suites : 52 suites
Comment by Olivier Langlois (lano1106) - Monday, 04 March 2013, 15:52 GMT
With the help of Pierre, I think that I have found the guilty component...

The protocol version that we see in the ClientHello message correspond to a specific TLS version

Protocol v3.1 == TLS 1.0
Protocol v3.2 == TLS 1.1
Protocol v3.3 == TLS 1.2

Since for some user openssl-1.0.1.e works perfectly well, nothing is wrong with the library or the server. My explanation is that in some networking setup there is a monitoring router that do not support TLS 1.2 and just do not allow the connection to happen.

I just rebuild 1.0.1.e with OPENSSL_NO_TLS1_2_CLIENT and

# Do not test TLS1.2 as we disabled it above using OPENSSL_NO_TLS1_2_CLIENT
sed 's/TLSv1.2 //g' -i test/testssl

in check() as it used to be and this has fixed my problem in my setup.

No idea how the maintainer will handle this as I guess that some users do need TLS 1.2. Perhaps a new openssl_no_tls12 package could be introduced in AUR for people needing it.
Comment by Patrick McCarty (pnorcks) - Wednesday, 06 March 2013, 02:22 GMT
I am encountering this issue as well with openssl-1.0.1.e-3, behind a proxy at work. If I revert to openssl-1.0.1.e-2, I am able to download packages from the AUR (with 'packer') like before.

I cannot reproduce the issue on a different machine that is not behind a proxy.
Comment by Brandon (hashstat) - Thursday, 12 September 2013, 16:40 GMT
I created a one-line patch that allows one to disable TLS 1.2 by setting the environment variable OPENSSL_NO_TLS1_2 such as this:

$ OPENSSL_NO_TLS1_2=1 aurget -Su

This will allow openssl to be built as usual and folks can selectively disable TLS 1.2. This is especially helpful for those of use who carry laptops between home and work and would like to use TLS 1.2 at home and disable it at work with the broken proxy.

The patch is attached along with a new PKGBUILD that also adds the pod fix from  FS#35868  and adds imake to makedepends (for makedepend). And I moved the patching to prepare().
Comment by william douglas (wdouglas) - Thursday, 12 September 2013, 16:42 GMT
Oh that is much nicer than my keeping around an old version of openssl to use at work.
Comment by Pierre Schmitz (Pierre) - Saturday, 02 November 2013, 20:40 GMT
As this is not a bug in openssl itself I'll close this one.

Loading...