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

27

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

Utiliser -k/ --insecureou ajouter insecureà my ~/.curlrcne fait aucune différence.

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

Lors de l'utilisation wgetsemble bien fonctionner. Fonctionne également lors des tests avec opensslcomme 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

— kenorb
source

20

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 par -2/ --sslv2ou -3/ --sslv3. Cela -Lvaut également la peine d'essayer si la page demandée a été déplacée vers un autre emplacement.

Dans mon cas, c'était un curlbogue ( trouvé dans OpenSSL ), il curlfallait donc le mettre à niveau vers la dernière version (> 7.40) et cela a bien fonctionné.

Voir également:

— kenorb
source

Oui, la mise à niveau de curl a résolu le problème pour moi. Merci.

— Simon East

La dernière boucle déteste le chiffrement RC4 obsolète que les anciens serveurs pourraient encore utiliser, donc j'ai fini par utiliser "--ciphers RC4" pour le permettre spécifiquement

— maxpolk

@SimonEast De quelle version vers quelle version avez-vous évolué?

— Olle Härstedt

5

À partir de Mavericks, Apple a fait passer le moteur TLS / SSL d'OpenSSL à son propre moteur de transport sécurisé en binaire cURL distribué par Apple, ce qui rompt l'utilisation du certificat client. Utilisez le binaire cURL de homebrew:

brew install curl
brew link curl --force

— Arul Selvan
source

1

brew link curl --forcene fonctionne plus, vous devez export "$(brew --prefix curl)/bin:$PATH"plutôt mettre votre .bash_profile.

— Lars Nyström

1

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

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

— Shimon Doodkin
source