web-dev-qa-db-fra.com

curl ne parvient pas à récupérer le contenu HTTPS: erreur: 14094410: routines SSL: ssl3_read_bytes: échec de la négociation de l'alerte sslv3

J'essaie d'accéder au site Web https://www.lawsociety.com.au avec curl sur Windows 10 et Ubuntu 16.04. Il fonctionne sur Ubuntu, mais échoue sur Windows avec le message error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. Je ne sais pas ce qui ne va pas et comment y remédier.

Voici la sortie curl sur la machine 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

version 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    

Même commande sur la boîte 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

J'ai essayé openssl s_client commande sous 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)
---

La connexion semble donc très bien. L'ouverture de l'URL dans un navigateur fonctionne également très bien.

Qu'est-ce que je rate?

MISE À JOUR

1. L'un des problèmes possibles est que le site Web utilise un chiffrement RC4-SHA obsolète. J'ai essayé de l'activer explicitement avec curl, mais curl le rejette:

> 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. Un autre problème potentiel est que les certificats racine peuvent ne pas être disponibles. Cependant, curl est fourni avec le dernier bundle Mozilla CA (curl-ca-bundle.crt), donc je crois qu'il utilise des certificats corrects.

J'ai également copié tous les certificats publics de la boîte Ubuntu fonctionnant sur la machine Windows et spécifié le chemin du certificat pour boucler en utilisant --capath param - cela n'aide pas.

. Juste pour être complet, j'ai essayé avec la dernière Python 3.6.4:

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

SSL Python doit utiliser les fonctionnalités Windows pour HTTPS. Cependant, il échoue avec la même erreur:

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)>

Il semble donc que le problème ne vient pas du certificat manquant, mais se produit quelque part plus tôt. Je ne suis pas un expert SSL, donc je peux me tromper.

SOLUTION

La cause principale du problème est le protocole SSL obsolète + les chiffres utilisés par le site Web. Afin de faire fonctionner curl, je l'ai rétrogradé vers la version qui utilise OpenSSL 1.0.2, qui prend toujours en charge les chiffres RC4. Après cela, tout fonctionne parfaitement.

Pour ceux qui ont besoin de 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())
5
Alex Blekhman

Je pense qu'il y a en fait deux problèmes qui se chevauchent quelque peu, tous deux liés au serveur apparemment dépassé ou bien exploité de manière insensée. L'analyse par ssllabs montre qu'il ne prend en charge que les protocoles SSLv3 et TLSv1.0, et seulement quatre suites de chiffrement:

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

(qui dans le schéma de dénomination OpenSSL sont DES-CBC-SHA, DES-CBC3-SHA, RC4-MD5 et RC4-SHA).

Premièrement, comme indiqué par SSLLabs, le serveur est "intolérant à la version"; si vous lui envoyez ClientHello proposant des versions supérieures à 1.0 dans un enregistrement avec la version 1.0 (et autrement acceptable), il négocie à 1.0 comme il se doit *, mais si vous envoyez cette offre avec la version record 1.1 ou 1.2, comme certains logiciels le font (mais pas AFAICT tout OpenSSL récent), le serveur abandonne avec l'alerte close_notify (ce qui n'est pas correct pour cet état). (*: eh bien, comme il convient étant donné qu'il prend en charge 1.0 du tout)

Deuxièmement, il ne prend en charge que les quatre suites de chiffrement ci-dessus. Les versions très récentes d'OpenSSL et spécifiquement 1.1.0g ne prennent plus en charge le single-DES (du tout) car il est complètement cassé, et ne prennent pas en charge RC4 ou triple-DES par défaut à cause de divers biais et l'attaque d'anniversaire générique ; ainsi, si OpenSSL est utilisé, il n'y a pas de ciphersuites en commun et le serveur abandonne correctement avec alert handshake_failure. Mais il devrait être possible d'activer RC4 et/ou TDES, sauf s'ils ont été configurés au moment de la compilation (compilation). Je remarque que votre version Windows affiche (WinSSL) en plus à OpenSSL/1.1.0g; Je ne sais pas si cela signifie que schannel est utilisé ici (ou pas du tout), auquel cas cela pourrait être la raison --ciphers RC4-SHA (en utilisant le schéma de nommage OpenSSL) n'a pas fonctionné.

Remarque sur les programmes Windows, en particulier les `` importations '' comme curl et OpenSSL, ne partagent généralement pas les bibliothèques comme ils le font sur Unbuntu et la plupart des Linux (et autres Unix). Vous pourriez essayer openssl version sur votre Windows OpenSSL pour voir de quoi il s'agit; Je parie que ce n'est pas le dernier et si vous obtenez le dernier, il présentera le même problème depuis la ligne de commande.

Ubuntu 16.04 (je suppose que LTS?) Ne saigne pas Edge et il est logique qu'il prenne toujours en charge les chiffres qui ne sont obsolètes que récemment.

5
dave_thompson_085

Le problème vient de l'algorithme de hachage et du chiffrement des sites Web. Au moins RC4 a été déclaré dangereux il y a longtemps, donc de nombreux programmes refusent de l'utiliser. De plus, certains algorithmes SHA ne sont pas sûrs non plus. Le code de chiffrement réel peut avoir été complètement supprimé du logiciel.

--- Mauvaise réponse précédente ---

Il manque dans votre version de Windows OpenSSL les certificats racine approuvés qui sont utilisés pour vérifier le certificat TLS du serveur distant.

Il s'agit de la ligne de Windows CURL où il charge les certificats de vérification:

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

Et entrée similaire sous Linux:

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

Cela se produit car Windows OpenSSL ne prend pas en charge le magasin de certificats Windows, vous devez installer manuellement les certificats là-bas.

https://maulwuff.de/research/ssl-debugging.html#hdr3. contient des informations sur le problème et comment le résoudre.

0
Tero Kilkanen

J'ai eu un problème comme ça. Cette erreur de message " erreur cURL 35: erreur: 14094410: routines SSL: ssl3_read_bytes: échec de la négociation de l'alerte sslv3 (http_request_failed) " apparaît sur wordpress.

J'essayais de configurer Jetpack of wordpress et j'utilisais cloudflare.

J'ai pu le corriger en cliquant sur le bouton Enalbe Universal SSL sur CloudFlare.

0
Saulo Souza