curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Question

When I try to connect to any server (e.g. google.com) using curl (or libcurl) I get the error message:

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Verbose output:

$ curl www.google.com --verbose 
* Rebuilt URL to: www.google.com/ 
* Uses proxy env variable no_proxy == 'localhost,127.0.0.1,localaddress,.localdomain.com' 
* Uses proxy env variable http_proxy == 'https://proxy.in.tum.de:8080' 
* Trying 131.159.0.2... 
* TCP_NODELAY set 
* Connected to proxy.in.tum.de (131.159.0.2) port 8080 (#0) 
* successfully set certificate verify locations: 
* CAfile: /etc/ssl/certs/ca-certificates.crt 
 CApath: none 
* TLSv1.3 (OUT), TLS handshake, Client hello (1): 
* error:1408F10B:SSL routines:ssl3_get_record:wrong version number 
* Closing connection 0 
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number' 

For some reason curl seems to use TLSv1.3 even if I force it to use TLSv1.2 with the command --tlsv1.2 (it will still print TLSv1.3 (OUT), ..." I am using the newest version of both Curl and OpenSSL :

$ curl -V 
curl 7.61.0-DEV (x86_64-pc-linux-gnu) libcurl/7.61.0-DEV OpenSSL/1.1.1 zlib/1.2.8 
Release-Date: [unreleased] 
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets HTTPS-proxy 

I think this is a problem related to my installation of the programms. Can somebody explain to me what this error message means?

Answer 1

* Uses proxy env variable http_proxy == 'https://proxy.in.tum.de:8080' 
 ^^^^^

The https:// is wrong, it should be http://. The proxy itself should be accessed by HTTP and not HTTPS even though the target URL is HTTPS. The proxy will nevertheless properly handle HTTPS connection and keep the end-to-end encryption. See HTTP CONNECT method for details how this is done.

• Dmitrijs Čornobiļs: if you have this error in Docker, exposing port 443 to public fixed this problem
• akostadinov: Funny thing. This helped me understand that a site was blocked in Ukraine. After reading this answer I did curl http://siteiwouldnotmention.com:443/ and I saw the message that site was intentionally blocked.
• P.D: If see this error when you push code to git, delete the HTTPS_PROXY from environment variables. There is an option to add this in intellij via HTTP Porxy Settings for local testing.
• afarah: Thought I'd share what was the issue in my case... curl could reach the server, which in turn attempted to make an https call through a proxy (envoy), which failed with the error from the question, which was returned back to the client (curl). So, basically the same answer, except the proxy was behind the server not in front of it, and the error was on a server call (backend) not on the client call (curl). The fact that the server error was forwarded to the client caused some confusion...
• jave.web: @Dr.X or fix the URL to http:// which is the common setup between internal services

Answer 2

If anyone is getting this error using Nginx, try adding the following to your server config:

server {
 listen 443 ssl;
 ...
}

The issue stems from Nginx serving an HTTP server to a client expecting HTTPS on whatever port you're listening on. When you specify ssl in the listen directive, you clear this up on the server side.

• normic: thx, this led me to the solution, simply missed the 'ssl' in the mentioned nginx config line
• arturas: ssl was an issue for me too
• Ant: Much better than the green check!

Answer 3

This is a telltale error that you are serving HTTP from the HTTPS port.

You can easily test with telnet

telnet FQDN 443
GET / HTTP/1.0
[hit return twice]

and if you see regular HTTP document here [not some kind of error], you know that your configuration is incorrect and the responding server is not SSL-encrypting the response.

• Mijo: Saved me with traffic server, where I forgot to add SSL after the port 443 in records.config.
• oxwilder: Can you add more to this answer? I confirmed with your method that I was getting html as a response, but I don't know what to do about it.
• Bret Weinraub: @oxwilder - that will depend on the type of web server you are using, apache, nginx, IIS, litespeed, something else?

Answer 4

Simple answer

If you are behind a proxy server, please set the proxy for curl. The curl is not able to connect to server so it shows wrong version number. Set proxy by opening subl ~/.curlrc or use any other text editor. Then add the following line to file:

proxy= proxyserver:proxyport

For e.g. proxy = 10.8.0.1:8080

If you are not behind a proxy, make sure that the curlrc file does not contain the proxy settings.

Answer 5

Also check your /etc/hosts file. Wasted 2 hours on this. If you have an url rerouted to 127.0.0.1 or any other loopback, this will fail the ssl handshake.

• stats con chris: can you explain more this.. what did you have exactly in hosts
• 1D0BE: Your hosts file contains 'custom routes' that skip the dns lookup and get straight routed to wherever is specified in it. If you have an adress routed to yourself (maybe because you are hosting something or for whatever other reason), you might encounter this error.
• micah94: I encountered this exact reason/error because a server was set up incorrectly with the full domain pointing to 127.0.1.1 inside /etc/hosts rather than allowing DNS to handle the request. Quite possibly as a placeholder before going live.

Answer 6

In my case the cause of this error was that my web server was not configured to listen to IPv6 on SSL port 443. After enabling it the error disappeared.

Here's how you do it for Apache:

<VirtualHost ip.v4.address:443 ip:v::6:address:443>
...
</VirtualHost>

And for nginx:

listen 443 ssl http2;
listen [::]:443 ssl http2; 

Answer 7

Another possible cause of this problem is if you have not enabled the virtual host's configuration file in Apache (or if you don't have that virtual host at all) and the default virtual host in Apache is only configured for non-SSL connections -- ie there's no default virtual host which can talk SSL. In this case because Apache is listening on port 443 the request for the virtual host that doesn't exist will arrive at the default virtual host -- but that virtual host doesn't speak SSL.

• user256717: This was the case for us and sudo a2ensite <site> fixed it.

Answer 8

I suffered the same problem and the cause was the wrong mix of IPv4 and IPv6 traffic. My Apache vhost was bound to an IPv4 address:

<VirtualHost 1.2.3.4:443>

I saw TCP connection RESET (checked with tpctrack) on the server side and ssl3_get_record:wrong version number testing with CURL on the client side.

The problem was traffic being either IPv4 ingress and IPv6 egress (or vice versa). The solution: Either configure the vhost to bind to both IP addresses (see: Ilyich's answer above) or define it as:

<VirtualHost *:443>

Answer 9

Thanks to @bret-weinraub,

I found that something is weird about the server's reply. After a bit of investigation, it turned out that I have a static IP in /etc/hosts file for the target domain and as they have changed their IP address I'm not getting to the correct server.

Answer 10

This can be caused by problems in how your network is configured. In my case it went away when I disconnected from airport wifi and used my phone hotspot instead.

Answer 11

I was facing similar issue. In my case it was resolved with correctly pointing out the server ip in /etc/hosts.

I gave server1 ip where http server was running on 8080 port, instead of server2 ip in /etc/hosts. Due to this miss configuration I was seeing this error.

Answer 12

More simply in one line:

proxy=192.168.2.1:8080;curl -v example.com

eg. $proxy=192.168.2.1:8080;curl -v example.com

xxxxxxxxx-ASUS:~$ proxy=192.168.2.1:8080;curl -v https://google.com|head -c 15 % Total % Received % Xferd Average Speed Time Time Time Current
 Dload Upload Total Spent Left Speed
 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Trying 172.217.163.46:443...
* TCP_NODELAY set
* Connected to google.com (172.217.163.46) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
 CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]

Answer 13

In the case of using MySQL CLI to connect to an external MySQL DB, depending on the version of MySQL, you can pass the --ssl-mode=disabled like:

$ mysql --ssl-mode=disabled -h yourhost.tld -p

Or simply in your client config, for example in /etc/my.cnf.d/client.cnf:

[client]
ssl-mode=DISABLED

---

This is for dev and sometimes security and these things can be forfeited in certain situations in a closed, private dev environment.

• Cameron Hudson: Disabling SSL is not a good idea for security.