Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 462348 - net-misc/wget-1.14 with dev-libs/openssl-1.0.1c - SSL handshake fails at
Summary: net-misc/wget-1.14 with dev-libs/openssl-1.0.1c - SSL handshake fails at http...
Status: RESOLVED DUPLICATE of bug 412859
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo's Team for Core System packages
Depends on:
Reported: 2013-03-19 18:17 UTC by Tobias Leupold
Modified: 2014-02-04 09:44 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Leupold 2013-03-19 18:17:32 UTC
After the upgrade to openssl-1.0.1c, (at least) wget doesn't work anymore with (at least some) SSL hosts. Running revdep-rebuild and also re-emerging wget didn't help.

For example:

	# LC_ALL=C wget --debug "" -O /dev/stdout 
	Setting --output-document (outputdocument) to /dev/stdout 
	DEBUG output created by Wget 1.14 on linux-gnu. 

	--2013-03-19 14:51:35-- 
	Caching => 
	Connecting to||:443... connected. 
	Created socket 4. 
	Releasing 0xb77d9a68 (new refcount 1). 
	Initiating SSL handshake. 
	SSL handshake failed. 
	closed fd 4 
	Unable to establish SSL connection.

There was no additional information in the logs or dmesg why exactly the SSL handshake failed.

With e. g. Opera, the same URL was accessible. After the downgrade to 1.0.0j, everything works fine again with wget (even without rebuilding it).

Happens both on my x86 server and my amd64 desktop.
Comment 1 Jeroen Roovers (RETIRED) gentoo-dev 2013-03-20 19:13:37 UTC
$ LC_ALL=C curl --verbose "" 
* About to connect() to port 443 (#0)
*   Trying
* Connected to ( port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
[here it hangs]

Maybe it's not specific to wget/openssl, then?
Comment 2 Tobias Leupold 2013-03-20 19:28:47 UTC
I think it's a general OpenSSL issue – I have the same problem like you have using curl, but it only happens with dev-libs/openssl-1.0.1c. I just tried the same "solution" like on my server and downgraded to dev-libs/openssl-1.0.0j. After that, it works again:

# LC_ALL=C curl --verbose "" 
* About to connect() to port 443 (#0)
*   Trying
* Connected to ( port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using RC4-SHA
* Server certificate:
*        subject: C=DE; ST=Berlin; L=Berlin; O=Strato AG; OU=Rechenzentrum; CN=*
*        start date: 2012-08-31 00:00:00 GMT
*        expire date: 2013-09-12 23:59:59 GMT
*        subjectAltName: matched
*        issuer: C=US; O=Thawte, Inc.; CN=Thawte SSL CA
*        SSL certificate verify ok.
> GET /nic/update HTTP/1.1
> User-Agent: curl/7.29.0
> Host:
> Accept: */*
< HTTP/1.1 401 Authorization Required
< Date: Wed, 20 Mar 2013 19:25:59 GMT
< Server: Apache/1.3.41 (Unix) mod_deflate/1.0.21 mod_perl/1.31 mod_ssl/2.8.31 OpenSSL/0.9.8o
< WWW-Authenticate: Basic realm="dyndns"
< Connection: close
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
<TITLE>401 Authorization Required</TITLE>
<H1>Authorization Required</H1>
This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.<P>
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
Comment 3 Tobias Leupold 2013-04-01 16:38:09 UTC
I just tried dev-libs/openssl-1.0.1e, the latest (testing) version and the problem is still the same, both with wget and curl (and probably others).
Comment 4 Panagiotis Christopoulos (RETIRED) gentoo-dev 2013-04-04 22:29:34 UTC
The problem seems to be that newer openssl versions by default try to connect to servers with TLS 1.2 and fail when servers support <1.2. If you add --secure-protocol=TLSv1 in wget you should be able to establish a secure connection with that server. It needs some research to be sure if this is a real bug and if it's already addressed upstream.
Comment 5 Tobias Leupold 2013-04-07 18:08:11 UTC
Anyway, adding "--secure-protocol=TLSv1" to the wget call makes it work again. Thanks :-)
Comment 6 Brian S. Stephan 2013-04-17 23:46:52 UTC
I can confirm I'm also seeing this, both on the domain in the subject, and on some internal hosts.

The basic version of the symptom is that of the following:

1. # openssl s_client -ssl3 -state -connect
2. # openssl s_client -tls1 -state -connect
3. # openssl s_client -tls1_2 -state -connect
4. # openssl s_client -state -connect

1 and 2 handshake successfully and retrieve the cert, 3 and 4 hang at the following:

# openssl s_client -state -connect 
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
[hang, wait for connection reset]
SSL_connect:error in SSLv2/v3 read server hello A

If there is interest I can try to get some pcaps from both sides via internal testing.

I'll note that while the flag for wget and s_client solves these cases, this is also impacting software using openssl as a library, as I initially found this problem when suds (a Python web service client) requests were hanging.
Comment 7 Tobias Leupold 2013-04-18 10:16:02 UTC
I think somebody who knows what he/she does should evaluate if this is actually a Gentoo specific problem or a problem of OpenSSL itself. If so, I think this should be reported to the OpenSSL folks, as other distros would be affected as well – just to avoid investigation being made multiple times.
Comment 8 Alexander E. Patrakov 2014-01-29 20:54:23 UTC
The testcase no longer works - it looks like has fixed their server. Anyway, this bug looks like a dupe of and should be closed.
Comment 9 SpanKY gentoo-dev 2014-02-04 09:44:31 UTC

*** This bug has been marked as a duplicate of bug 412859 ***