Can't wget from github, sslv3 handshake error

Question

We have a script that downloads mod security from github that has recently started failing. The servers run CentOS 6 but RHEL 6 probably has the same issue. The output is:

# wget https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
--2014-07-22 18:49:46--  https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
Resolving github.com... 192.30.252.129
Connecting to github.com|192.30.252.129|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://cloud.github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz [following]
--2014-07-22 18:49:47--  https://cloud.github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz
Resolving cloud.github.com... 54.230.99.219, 205.251.219.190, 54.230.97.212, ...
Connecting to cloud.github.com|54.230.99.219|:443... connected.
OpenSSL: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
Unable to establish SSL connection.

Any ideas on how to fix or work around this?

To be more specific, both 54.230.99.219 and several of the (different) A's I get for cloud.github.com give handshake failure to s_client without option for ServerNameIndication. http://serverfault.com/questions/560053/curl-succeeds-on-an-https-request-wget-does-not says (several months ago) RedHat wget doesn't do SNI but curl does. — dave_thompson_085, Jul 23 '14 at 00:32
You feel lucky to accept my **[answer](http://unix.stackexchange.com/a/146010/50478)** — Anton Dozortsev, Jul 23 '14 at 16:25
Well, to be honest I would prefer if @dave_thompson_085 or Rabin posted their comments as answers as I see that as more of a long term solution even though your workaround also works great! — Kristofer, Jul 24 '14 at 08:32

score 11 · Answer 1 · edited Aug 22 '16 at 16:10

11

You can use the curl command to download it:

curl -LO https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz

edited Aug 22 '16 at 16:10

HalosGhost

4,732
10
33
41

answered Aug 22 '14 at 12:35

rajesh gupta

111
2

5

`curl -L -O` is a better replacement for `wget`, since it follows HTTP redirects (particularly useful here since Github wants to point me to its CDN). – strangefeatures Nov 18 '14 at 04:43
Also, one thing I ran into with the versions in CentOS 6.5 is that `curl` supports SNI and `wget` does not, so for some sites `wget` will sometimes be served the certificate for the wrong host and get a certificate failure, even if `curl` works fine. – rakslice Dec 16 '14 at 02:41

score 7 · Answer 2 · answered Jun 02 '15 at 15:07

Server side has disabled the SSLv3 encryption handshake, because of SSLv3 severe security issues. Moreover, your wget client is an outdated version and still use as default this SSLv3 encryption. You have 2 options:

use --secure-protocol=TLSv1 flag in front of wget. wget --secure-protocol=TLSv1
install an updated version of wget that use as default TLSv1 protocol

score 5 · Answer 3 · edited Jan 16 '15 at 14:37

5

You should check your wget version.

I had the same problem with older versions of wget (< 1.15).

edited Jan 16 '15 at 14:37

Anthon

78,313
42
165
222

answered Jan 16 '15 at 13:35

Dan

61
1
1

2

This looks like this should be a comment against the question, and not an answer. – Danny Staple Jan 16 '15 at 13:54

score 2 · Accepted Answer · edited Mar 27 '15 at 18:02

2

If I'm not mistaken you mean this repo. Try to get URL form Releases.

This case work for me:

$ wget https://github.com/SpiderLabs/ModSecurity/archive/v2.8.0.tar.gz

P.S. I also have the same error message when try to run your case;

$ wget https://github.com/downloads/SpiderLabs/ModSecurity/modsecurity-apache_2.7.1.tar.gz

edited Mar 27 '15 at 18:02

kenorb

20,250
14
140
164

answered Jul 22 '14 at 22:19

Anton Dozortsev

224
1
5
14

Hmm, this URL does not have an md5 though :( – Kristofer Aug 20 '14 at 12:37
https://raw.githubusercontent.com/${USER}/${REPO}/path/to/file.tar.gz – Maksim Kostromin Feb 22 '18 at 23:43

score 0 · Answer 5 · answered Feb 02 '16 at 11:36

As for workaround, if you trust the host try specifying --no-check-certificate or add:

check_certificate = off

into your ~/.wgetrc (not recommended).

In some rare cases, it's caused by your system time which could be out-of-sync therefore invalidating the certificates which was working before.

score -1 · Answer 6 · answered Apr 24 '20 at 07:37

-1

Try this:

update-crypto-policies --set LEGACY

answered Apr 24 '20 at 07:37

José Luis González Chacón

1

3

Welcome to the site, and thank you for your contribution. Would you mind editing your post to include some explanation, i.e. in particular which of the symptoms described by the OP leads you to conclude that the crypto policies are the issue, and why changing them in this way can solve them? The idea is to have answers as self-contained as possible so that they are useful not only to the OP, but others facing similar problems, too. – AdminBee Apr 24 '20 at 08:09
1

If this is the tool introduced by RHEL 8, you should say that, and also realize that this question is about RHEL6. – Jeff Schaller Apr 24 '20 at 12:00

Can't wget from github, sslv3 handshake error

6 Answers6