web-dev-qa-db-fra.com

Comment réparer l'échec de la négociation de l'alerte curl sslv3?

J'essaie de boucler le site Web HTTPS de la manière suivante:

$ curl -v https://thepiratebay.se/

Cependant, il échoue avec l'erreur:

* About to connect() to thepiratebay.se port 443 (#0)
*   Trying 173.245.61.146...
* connected
* Connected to thepiratebay.se (173.245.61.146) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS alert, Server hello (2):
* error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure
* Closing connection #0
curl: (35) error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

En utilisant -k/--insecure ou en ajoutant insecure à mon ~/.curlrc ne fait aucune différence.

Comment ignorer ou forcer le certificat à l'aide de la ligne de commande curl?

Lorsque vous utilisez wget semble fonctionner correctement. Fonctionne également lors des tests avec openssl comme ci-dessous:

$ openssl s_client -connect thepiratebay.se:443
CONNECTED(00000003)
SSL handshake has read 2651 bytes and written 456 bytes
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA

J'ai:

$ curl --version
curl 7.28.1 (x86_64-Apple-darwin10.8.0) libcurl/7.28.1 OpenSSL/0.9.8| zlib/1.2.5 libidn/1.17
Protocols: dict file ftp ftps Gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp 
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz
command-lineosxcurlssl
28
kenorb

Certains sites désactivent la prise en charge de SSL 3.0 (possible en raison de nombreux exploits/vulnérabilités), il est donc possible de forcer une version SSL spécifique soit par -2/--sslv2 ou -3/--sslv3. Aussi -L mérite un essai si la page demandée a été déplacée vers un autre emplacement.

Dans mon cas, c'était un bogue curl ( trouvé dans OpenSSL ), donc curl devait être mis à niveau vers la dernière version (> 7.40) et cela fonctionnait bien.

Voir également:

21
kenorb

À partir de Mavericks, Apple a basculé le moteur TLS/SSL d'OpenSSL vers son propre moteur de transport sécurisé dans Apple binaire cURL distribué qui rompt l'utilisation du certificat client. Utilisez le binaire cURL de homebrew:

brew install curl
brew link curl --force
6
Arul Selvan

J'ai eu cette erreur lorsque j'envoyais un en-tête d'hôte incorrect.

Je développais un proxy de http://127.0.0.1:12345 à https://site.com:44 . donc j'envoyais des en-têtes de demande tels quels, comme cela venait du navigateur et il y avait un en-tête Host: 127.0.0.1: 12345. J'ai supprimé l'en-tête Host provenant du navigateur pour résoudre le problème.

1
Shimon Doodkin