curl: (35) 错误:1408F10B:SSL 例程:ssl3_get_record:版本号错误



当我尝试使用 curl(或 libcurl(连接到任何服务器(例如 google.com(时,我收到错误消息:

curl: (35( 错误:1408F10B:SSL 例程:ssl3_get_record:错误的版本号

详细输出:

$ 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'  

出于某种原因,curl 似乎使用 TLSv1.3,即使我强制它使用带有命令 --tlsv1.2 的 TLSv1.2(它仍然会打印 TLSv1.3 (OUT(,..." 我正在使用最新版本的Curl和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  

我认为这是一个与我安装程序有关的问题。 有人可以向我解释此错误消息的含义吗?

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

https://是错误的,应该是http://。代理本身应该通过HTTP而不是HTTPS访问,即使目标URL是HTTPS。尽管如此,代理将正确处理HTTPS连接并保持端到端加密。请参阅 HTTP CONNECT 方法,详细了解如何完成此操作。

如果有人在使用 Nginx 时收到此错误,请尝试将以下内容添加到您的服务器配置中:

server {
listen 443 ssl;
...
}

该问题源于Nginx向期望在您正在侦听的任何端口上使用HTTPS的客户端提供HTTP服务器。在listen指令中指定ssl时,将在服务器端清除此内容。

这是一个明显的错误,表明您正在从HTTPS端口提供HTTP。

您可以使用 telnet 轻松进行测试

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

如果您在此处看到常规 HTTP 文档 [不是某种错误],则表明您的配置不正确,并且响应服务器未对响应进行 SSL 加密。

简单的答案

如果您在代理服务器后面,请为 curl 设置代理。curl 无法连接到服务器,因此显示错误的版本号。 通过打开subl ~/.curlrc或使用任何其他文本编辑器来设置代理。然后将以下行添加到文件中:

proxy= proxyserver:proxyport

例如proxy = 10.8.0.1:8080

如果不在代理后面,请确保 curlrc 文件不包含代理设置。

还要检查您的/etc/hosts文件。浪费了2个小时。如果将 url 重新路由到 127.0.0.1 或任何其他环回,则 SSL 握手将失败。

就我而言,此错误的原因是我的 Web 服务器未配置为侦听 SSL 端口 443 上的 IPv6。启用后,错误消失了。

以下是您为 Apache 执行此操作的方法:

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

对于nginx:

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

感谢@bret-weinraub,

我发现服务器的回复有些奇怪。经过一番调查,事实证明/etc/hosts目标域的文件中有一个静态IP,并且由于他们更改了IP地址,因此我无法访问正确的服务器。

更简单的一行:

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

例如。$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]

此问题的另一个可能原因是,如果您尚未在 Apache 中启用虚拟主机的配置文件(或者您根本没有该虚拟主机(,并且 Apache 中的默认虚拟主机仅配置为非 SSL 连接 - 即没有可以通信 SSL 的默认虚拟主机。在这种情况下,由于 Apache 正在侦听端口 443,因此对不存在的虚拟主机的请求将到达默认虚拟主机 - 但该虚拟主机不会使用 SSL。

在使用MySQL CLI连接到外部MySQL DB的情况下,根据MySQL的版本,您可以传递如下--ssl-mode=disabled

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

或者只是在您的客户端配置中,例如在/etc/my.cnf.d/client.cnf中:

[client]
ssl-mode=DISABLED

这是针对开发人员的,有时是安全性的,在某些情况下,在封闭的私有开发环境中,这些东西可能会被没收。

最新更新