Centos 7 上的 CURL 出现 NSS 错误 -12188答案

【问题标题】：CURL on Centos 7 getting NSS error -12188Centos 7 上的 CURL 出现 NSS 错误 -12188
【发布时间】：2020-03-21 09:04:10
【问题描述】：

我尝试向运行HTTPS 的网站发送GET 请求，但总是收到curl: (35) Peer reports it experienced an internal error.，我仅在该网站上收到此错误。当我尝试向 Youtube、Google 和其他 HTTPS 站点发送 GET 请求时，它们与我的 curl 配合得很好。这是我服务器上 curl 详细模式的信息。

# curl -v https://***.vn > test.htm
  % 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 103.x.x.x:443...
* TCP_NODELAY set
* Connected to ***.vn (103.x.x.x) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: none
  CApath: none
* loaded libnssckbi.so
* NSS error -12188 (SSL_ERROR_INTERNAL_ERROR_ALERT)
* Peer reports it experienced an internal error.
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (35) Peer reports it experienced an internal error.

我已经用yum update 更新了我的服务器，并将 curl 更新到了最新版本，但仍然无法正常工作。之后，我尝试从我的 Macbook 发送请求，当阅读结果时，我知道我的 Mac 上的 curl 也使用 ECDHE-RSA-AES256-GCM-SHA384 密码作为 TSLv1.2。

Viets-MacBook-Pro:~ vietnguyen$ curl -v https://*****.vn > test.htm
* Rebuilt URL to: https://*****.vn/
  % 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 103.xx.xx.xx...
* TCP_NODELAY set
* Connected to *****.vn (103.xx.xx.xx) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [217 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [93 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [3177 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: businessCategory=Private Organization; serialNumber=.....; CN=*****.vn
*  start date: Dec 11 06:22:40 2018 GMT
*  expire date: Dec 11 06:22:40 2020 GMT
*  subjectAltName: host "*****.vn" matched cert's "*****.vn"
*  issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign Extended Validation CA - SHA256 - G3
*  SSL certificate verify ok.
> GET / HTTP/1.1
> Host: *****.vn
> User-Agent: curl/7.54.0
> Accept: */*
> 
  0     0    0     0    0     0      0      0 --:--:--  0:00:01 --:--:--     0< HTTP/1.1 200 OK
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Server: Microsoft-IIS/10.0
< X-Powered-By: ASP.NET
< X-XSS-Protection: 1;mode=block
< Date: Thu, 20 Feb 2020 13:41:32 GMT
< Content-Length: 73711
< 
{ [7804 bytes data]
100 73711  100 73711    0     0  39172      0  0:00:01  0:00:01 --:--:-- 39166
* Connection #0 to host *****.vn left intact

但是当我在我的网络服务器上使用选定的密码运行 curl 时出现错误 Unknown cipher in list 然后即使我使用最新的 curl 版本并更新我的网络服务器。

[root@localhost vietnguyen]# curl --ciphers ECDHE-RSA-AES256-GCM-SHA384 -v https://*****.vn > test.htm
  % 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 103.xx.xx.xx:443...
* TCP_NODELAY set
* Connected to *****.vn (103.xx.xx.xx) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* Unknown cipher in list: ECDHE-RSA-AES256-GCM-SHA384
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
* Closing connection 0
curl: (59) Unknown cipher in list: ECDHE-RSA-AES256-GCM-SHA384

我的 curl 版本

# curl -V
curl 7.68.0 (x86_64-redhat-linux-gnu) libcurl/7.68.0 NSS/3.44 zlib/1.2.7 libpsl/0.7.0 (+libicu/50.1.2) libssh2/1.9.0 nghttp2/1.31.1
Release-Date: 2020-01-08
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy IPv6 Kerberos Largefile libz Metalink NTLM NTLM_WB PSL SPNEGO SSL UnixSockets

我还运行yum update nss nss-util nss-sysinit nss-tools 到最新的nss 版本仍然无法正常工作。

我的 openssl 版本

# openssl version
OpenSSL 1.1.1d  10 Sep 2019

任何人都可以解决这个问题吗？

【问题讨论】：

您的 OpenSSL 版本无关紧要；您在 CentOS 上的 curl 使用的是 NSS 而不是 OpenSSL。对于 NSS 密码套件名称的拼写不同，请参阅 this doc page 的 NSS 部分；你想要ecdhe_rsa_aes_256_gcm_sha_384。您也可以查看openssl s_client -connect $host:443
@dave_thompson_085 感谢您的帮助，但是您有什么办法可以解决我的问题吗？我的 curl 仅在向该网站发送请求时失败，我到处搜索但找不到任何解决方案
这个 curl 版本是从哪里来的？根据我的测试系统and rpmfind，CentOS7 存储库中的（唯一）一个是 7.29@ 如果这没有给出任何线索，我会问服务器它认为问题是什么，或者如果那不可用，请获取网络跟踪并查看它，可能与来自其他客户端（Mac）或openssl（如果可行）的成功进行比较，尽管我已经查看了足够多的TLS跟踪，但我通常不需要比较。
@dave_thompson_085 我刚刚从 yum 安装了 CURL，你能在你的测试系统上测试通过 curl 到 vietlott.vn 的 get 请求吗？

标签： curl openssl centos7

【解决方案1】：

首先：我在 CentOS 7 上（更新后）

$ curl -V
curl 7.29.0 (x86_64-redhat-linux-gnu) libcurl/7.29.0 NSS/3.44 zlib/1.2.7 libidn/1.28 libssh2/1.8.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz unix-sockets
$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ yum list curl nss openssl 
[snip]
Installed Packages
curl.x86_64                       7.29.0-54.el7_7.2                    @updates
nss.x86_64                        3.44.0-7.el7_7                       @updates
openssl.x86_64                    1:1.0.2k-19.el7                      @anaconda
Available Packages
nss.i686                          3.44.0-7.el7_7                       updates
$ yum repolist
[snip]
repo id                             repo name                             status
base/7/x86_64                       CentOS-7 - Base                       10,097
extras/7/x86_64                     CentOS-7 - Extras                        335
updates/7/x86_64                    CentOS-7 - Updates                     1,774
repolist: 12,206

所有这些都与 rpmfind 一致，除了它的 nss 为 -4 —— 不是 curl 7.68 或 OpenSSL 1.1.1d。请检查 yum 说您已安装什么，以及来自哪个 repo（右侧列）。

无论如何，我的 curl/NSS 版本在该服务器上确实出现了同样的错误。使用wireshark进行捕获和解码，看起来像是一个合理的TLS1.2 ClientHello。我的 OpenSSL 1.0.2k（带有 RH/CentOS 添加的任何补丁）s_client 成功（只要我指定 -servername 现在广泛需要但在 1.0.2 中不是默认设置），我拥有的 OpenSSL 源代码构建也是如此在另一个系统上用于各种 1.0.2、1.1.0（相同的服务器名称）和 1.1.1（服务器名称现在是默认值）。由于 wget（可用于 CentOS7）使用 OpenSSL，wget 成功，并提供与 curl 基本相同的功能。

经过一些试验（使用 Java）后，该服务器似乎在使用 extension 用于 rfc5746（NSS 使用）的其他有效 TLS1.2 hello 上失败，但如果使用 SCSV（ OpenSSL 所做的）。这是相当糟糕的，因为 rfc 显然需要服务器支持两者。但是，除非您对服务器上使用的软件或中间件的开发人员有一定的影响，否则您可能对此无能为力，需要使用 wget 等解决方法。

NSS 似乎一直在使用扩展而不是 SCSV since 2013

更奇怪的是，Firefox 使用 NSS（虽然我找不到方法来判断哪个版本），而我当前的 68esr 发送带有重新协商扩展（不是 SCSV）的 TLS1.3 ClientHello 并成功.可能是服务器首先检查协议版本，然后以不同的方式处理 rfc5746（避免失败）或根本不处理，因为 TLS1.3 完全禁止重新协商，使 rfc5746 没有实际意义。

【讨论】：

谢谢你的工作，对不起，但我的英语不是很好，无法 100% 理解你的答案，但你想说的是我必须使用 wget 而不是 CURL？
我是说 wget 可以工作并且很容易替代。还有其他方法至少有一定的工作机会，但没有那么简单。
很抱歉我的回复晚了，但我喜欢修复 CURL，因为我将使用 PHP 来构建我自己的工具。无论如何，感谢您的宝贵时间。
我不相信你可以使用 NSS 让 curl 工作，除非你构建（然后维护）你自己修改过的 NSS。但是，如果您（重新）从源代码构建 curl 以使用 OpenSSL 和 not NSS，它应该可以工作。当然，您必须重新构建 PHP 才能使用该 libcurl。玩得开心。
再次感谢您的光临。我试试看