Назад | Перейти на главную страницу

curl не может получить содержимое HTTPS: ошибка: 14094410: подпрограммы SSL: ssl3_read_bytes: сбой подтверждения подтверждения sslv3

Я пытаюсь зайти на сайт https://www.lawsociety.com.au с помощью curl в Windows 10 и Ubuntu 16.04. Он работает в Ubuntu, но не работает в Windows с сообщением error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. Я не уверен, что не так и как это исправить.

Вот результат curl на машине с Windows:

> curl -i -v -I https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS alert, Server hello (2):
* error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure
* stopped the pause stream!
* Closing connection 0
curl: (35) error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

версия curl:

curl 7.57.0 (x86_64-pc-win32) libcurl/7.57.0 OpenSSL/1.1.0g (WinSSL) zlib/1.2.11 WinIDN libssh2/1.8.0 nghttp2/1.28.0
Release-Date: 2017-11-29
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 IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz TLS-SRP HTTP2 HTTPS-proxy MultiSSL    

Та же команда в поле Ubuntu:

$ curl -I -v https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs
* ALPN, offering http/1.1
* SSL connection using TLS1.0 / RSA_3DES_EDE_CBC_SHA1
*        server certificate verification OK
*        server certificate status verification SKIPPED
*        common name: *.lawsociety.com.au (matched)
*        server certificate expiration date OK
*        server certificate activation date OK
*        certificate public key: RSA
*        certificate version: #3
*        subject: C=AU,postalCode=2000,ST=NSW,L=Sydney,street=170 Phillip Street,O=THE LAW SOCIETY OF NEW SOUTH WALES,OU=PremiumSSL Wildcard,CN=*.lawsociety.com.au
*        start date: Fri, 17 Mar 2017 00:00:00 GMT
*        expire date: Mon, 16 Apr 2018 23:59:59 GMT
*        issuer: C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Organization Validation Secure Server CA
*        compression: NULL
* ALPN, server did not agree to a protocol
> HEAD / HTTP/1.1
> Host: www.lawsociety.com.au
> User-Agent: curl/7.47.0
> Accept: */*
>
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Tue, 26 Dec 2017 09:04:02 GMT
Date: Tue, 26 Dec 2017 09:04:02 GMT
< Server: Oracle-Application-Server-11g
Server: Oracle-Application-Server-11g
< Cache-Control: no-cache
Cache-Control: no-cache
< Content-Length: 36272
Content-Length: 36272
< Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
Set-Cookie: JSESSIONID=kGs3hCQCW7FPhQ2Lh0JvKn9JvXhhHCK2GQKXvLps308Ww1D70pMp!1826685759; path=/; HttpOnly
< X-ORACLE-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
X-ORACLE-DMS-ECID: 005OJeGQSZb9xWGayxQ_MG0007Z60000EU
< X-Powered-By: Servlet/2.5 JSP/2.1
X-Powered-By: Servlet/2.5 JSP/2.1
< Content-Type: text/html; charset=utf-8
Content-Type: text/html; charset=utf-8

<
* Connection #0 to host www.lawsociety.com.au left intact

Я попытался openssl s_client команда в Windows:

> openssl s_client -connect www.lawsociety.com.au:443
CONNECTED(00000224)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
 0 s:/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
   i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
 3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
... <removed to save space> ...
-----END CERTIFICATE-----
subject=/C=AU/postalCode=2000/ST=NSW/L=Sydney/street=170 Phillip Street/O=THE LAW SOCIETY OF NEW SOUTH WALES/OU=PremiumSSL Wildcard/CN=*.lawsociety.com.au
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Organization Validation Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 5683 bytes and written 621 bytes
---
New, TLSv1/SSLv3, Cipher is RC4-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-SHA
    Session-ID: 8198FE887E4FC12D68E2388D4C052ABF
    Session-ID-ctx:
    Master-Key: 93688C15A75E3E9F596AF96DFF72B557AD28A3FEF8764401CBD12D1F432EAF4D216595D74338AF24498AB29FF5ABE759
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1514278771
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---

Так что с подключением вроде все в порядке. Открытие URL-адреса в браузере тоже работает нормально.

Что мне не хватает?

ОБНОВИТЬ

1. Одна из возможных проблем заключается в том, что на сайте используется устаревший шифр RC4-SHA. Я пытался включить его явно с помощью curl, но curl отклоняет его:

> curl -i -v -I --ciphers "RC4-SHA" https://www.lawsociety.com.au
* Rebuilt URL to: https://www.lawsociety.com.au/
*   Trying 125.7.104.7...
* TCP_NODELAY set
* Connected to www.lawsociety.com.au (125.7.104.7) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* failed setting cipher list: RC4-SHA
* Closing connection 0
curl: (59) failed setting cipher list: RC4-SHA

2. Другая потенциальная проблема заключается в том, что корневые сертификаты могут быть недоступны. Однако curl поставляется с последней версией Mozilla CA (curl-ca-bundle.crt), поэтому я считаю, что он использует правильные сертификаты.

Я также скопировал все общедоступные сертификаты из рабочего окна Ubuntu на компьютер с Windows и указал путь к сертификату для curl, используя --capath param - не помогает.

3. Для полноты картины я попробовал использовать последнюю версию Python 3.6.4:

import urllib.request
with urllib.request.urlopen('https://www.lawsociety.com.au/') as u:
    print(u.read())

Python SSL должен использовать возможности Windows для HTTPS. Однако он не работает с той же ошибкой:

ssl.SSLError: [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)
...
During handling of the above exception, another exception occurred:
...
urllib.error.URLError: <urlopen error [SSL: SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:777)>

Так что, похоже, проблема не в отсутствии сертификата, а где-то раньше. Я не специалист по SSL, поэтому могу ошибаться.

РЕШЕНИЕ

Основная причина проблемы - устаревший протокол SSL + шифры, используемые сайтом. Чтобы curl работал, я понизил его до версии, использующей OpenSSL 1.0.2, которая все еще поддерживает шифры RC4. После этого все работает безупречно.

Для тех, кому нужно решение Python:

import ssl
import urllib.request

ctx = ssl.SSLContext(protocol=ssl.PROTOCOL_SSLv3)
ctx.set_ciphers('SSLv3')
# alternatively, for this particular website:
#ctx.set_ciphers('RC4-SHA:RC4-MD5')

with urllib.request.urlopen('https://www.lawsociety.com.au/', context=ctx) as u:
    print(u.read())

Я считаю, что на самом деле здесь есть две частично совпадающие проблемы, обе связаны с сервером, который явно устарел или работает безумно. Анализ по ssllabs показывает, что он поддерживает только протоколы SSLv3 и TLSv1.0 и только четыре набора шифров:

TLS_RSA_WITH_DES_CBC_SHA (0x9)   INSECURE   56
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)   WEAK  112
TLS_RSA_WITH_RC4_128_MD5 (0x4)   INSECURE   128
TLS_RSA_WITH_RC4_128_SHA (0x5)   INSECURE   128

(которые в схеме именования OpenSSL являются DES-CBC-SHA, DES-CBC3-SHA, RC4-MD5 и RC4-SHA).

Во-первых, как отмечает SSLLabs, сервер «нетерпим к версии»; если вы отправите его ClientHello, предлагая версии выше 1.0 в записи с версией 1.0 (и в противном случае приемлемо) он согласовывает до 1.0, как и должно *, но если вы отправляете это предложение с записью версии 1.1 или 1.2, как это делает какое-то программное обеспечение (но не AFAICT любого недавнего OpenSSL), сервер прекращает работу с предупреждением close_notify (что является не подходит для этого состояния). (*: ну, как и следовало ожидать, учитывая, что он вообще поддерживает 1.0)

Во-вторых, он поддерживает только четыре указанных выше набора шифров. Самые последние версии OpenSSL и, в частности, 1.1.0g больше не поддерживают одиночный DES (вообще), потому что он полностью сломан и не поддерживает RC4 или тройной DES. по умолчанию из-за различные предубеждения и общая атака на день рождения; таким образом, если используется OpenSSL, общих шифровальных наборов нет, и сервер корректно завершает работу с предупреждением handshake_failure. Но должна быть возможность включить RC4 и / или TDES, если они не были настроены во время сборки (компиляции). Я заметил, что ваша версия Windows показывает (WinSSL) к тому же к OpenSSL/1.1.0g; Я не знаю, означает ли это, что здесь используется канал (или вообще), и в этом случае это может быть причиной --ciphers RC4-SHA (с использованием схемы именования OpenSSL) не сработало.

Обратите внимание на программы Windows, особенно на «импорт», такие как curl и OpenSSL, обычно не используют общие библиотеки, как это происходит в Unbuntu и большинстве Linux (и других Unix). Вы можете попробовать openssl version на вашем Windows OpenSSL, чтобы узнать, что это такое; Бьюсь об заклад, это не последняя версия, и если вы ее получите, в командной строке будет отображаться та же проблема.

Ubuntu 16.04 (я полагаю, LTS?) Не является передовой, и имеет смысл поддерживать шифры, которые были объявлены устаревшими только недавно.

У меня была такая проблема. Это сообщение об ошибке "Ошибка cURL 35: ошибка: 14094410: подпрограммы SSL: ssl3_read_bytes: сбой подтверждения подтверждения sslv3 (http_request_failed)"найти на wordpress.

Я пытался настроить Реактивный ранец из Wordpress и я использовал облачная вспышка.

Я мог исправить это, нажав на кнопку Универсальный SSL Энальбе на CloudFlare.

Проблема заключается в алгоритме хеширования и шифре веб-сайтов. По крайней мере, RC4 давно объявлен небезопасным, поэтому многие программы отказываются его использовать. Кроме того, некоторые алгоритмы SHA тоже небезопасны. Фактический шифровальный код мог быть полностью удален из программного обеспечения.

--- Предыдущий неправильный ответ ---

В вашей версии Windows OpenSSL отсутствуют доверенные корневые сертификаты, которые используются для проверки сертификата TLS удаленного сервера.

Это строка из Windows CURL, куда загружаются сертификаты проверки:

* successfully set certificate verify locations:
*   CAfile: D:\dev\curl\bin\curl-ca-bundle.crt

И аналогичная запись в Linux:

* found 148 certificates in /etc/ssl/certs/ca-certificates.crt
* found 594 certificates in /etc/ssl/certs

Это происходит потому, что Windows OpenSSL не поддерживает хранилище сертификатов Windows, вам необходимо вручную установить сертификаты там.

https://maulwuff.de/research/ssl-debugging.html#hdr3.3 есть информация о проблеме и способах ее решения.