CURL на Centos 7 получает ошибку NSS -12188 - PullRequest
0 голосов
/ 17 марта 2020

Я пытался отправить GET запрос на веб-сайт с HTTPS, но всегда получал curl: (35) Peer reports it experienced an internal error., и я получаю эту ошибку только на этом веб-сайте. Когда я пытался отправить запрос GET на Youtube, Google и другие HTTPS-сайты, они отлично работали с моим 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, и когда я прочитал результат, я узнал свой скручиваемость на своем Ma c, используя также шифры 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

Может кто-нибудь есть идеи, чтобы это исправить?

1 Ответ

1 голос
/ 21 марта 2020

Первое: у меня на 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 - не скручивание 7.68 или OpenSSL 1.1.1d. Пожалуйста, проверьте, что Yum говорит, что вы установили, и из какого репозитория (правая колонка).

В любом случае, моя версия 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) кажется, что этот сервер завершается с ошибкой в ​​другом действительном TLS1.2 hello, который использует расширение для rfc5746 (что делает NSS), но завершается успешно, если используя SCSV (что делает OpenSSL). Это довольно плохо, так как rf c явно требует поддержки сервера для обоих. Однако, если вы не имеете какого-либо влияния на разработчиков программного обеспечения или промежуточного программного обеспечения, используемого на сервере, вы, вероятно, ничего не можете с этим поделать, и вам потребуется обходной путь, например, wget.

Похоже, что NSS использует расширение вместо SCSV с 2013 года

Четная вероятность, Firefox использует NSS (хотя я не могу найти способ определить, какая версия), и мой текущий 68esr отправляет TLS1.3 ClientHello с расширением пересмотра (не SCSV) и успешно. Может случиться так, что сервер сначала проверяет версию протокола, а затем обрабатывает rfc5746 по-разному (избегая сбоя) или вообще не работает, поскольку TLS1.3 полностью запрещает повторное согласование, что делает спор по rfc5746.

...