cURL ne se connecte pas à HTTPS alors que wget le fait (erreur NSS -12286)

8

Je reçois une erreur NSS error -12286lors du téléchargement d'un fichier à partir de HTTPS à l'aide de curl.

Je peux télécharger le même fichier sans problème en utilisant wgetainsi je peux exclure tout problème de pare-feu ou de liste noire.

Déjà essayé, sans chance, les options -ket --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, c'est le chiffrement préféré du serveur selon l'outil Qualys SSL Labs Test Server ici: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest

Voici le cURLjournal:

# curl -v https://www.intribunale.net/immobili
* About to connect() to www.intribunale.net port 443 (#0)
*   Trying 104.27.150.214... connected
* Connected to www.intribunale.net (104.27.150.214) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12286
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error

Mes versions de lib sont:

# curl -V
curl 7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.19.1 Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Protocols: tftp ftp telnet dict ldap ldaps http file https ftps scp sftp
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz
curl nss Marco Marsala
la source
Pertinent: www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/… où il est indiqué que l'erreur NSS -12286 signifie SSL_ERROR_NO_CYPHER_OVERLAP«Impossible de communiquer en toute sécurité avec l'homologue: pas d'algorithme (s) de chiffrement commun (s)». Les systèmes locaux et distants ne partagent aucune suite de chiffrement en commun. Cela peut être dû à une mauvaise configuration à chaque extrémité. Cela peut être dû à une configuration incorrecte du serveur pour utiliser un certificat non RSA avec l'algorithme d'échange de clés RSA.
Celada
2
Je peux reproduire votre problème avec CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 sur un serveur de test. Par défaut, il n'offre aucune suite ECC, et puisque votre serveur (Cloudfare) accepte uniquement certaines suites ECC (spécifiquement ECDHE), la négociation échoue. En --cipher[s]spécifiant cette suite ECDHE, il n'envoie même pas ClientHello, ferme simplement la connexion et donne l'erreur. Cela semble être quelque chose de désynchronisé en interne, peut-être après le long déni d'ECC par RedHat. RedHat wget utilise OpenSSL, et le récent RedHat OpenSSL prend en charge ECC (uniquement avec P256 P384 P521 mais cela suffit ici).
dave_thompson_085
1
Mon premier choix serait (0) de ne pas utiliser (cette) boucle, mais si vous voulez vraiment que les options que je vois sont: (1) si vous avez du support, signalez-le comme un bug et espérez qu'il le corrige. (2) c'est open source; déboguez et corrigez-le vous-même. (3) c'est open source; reconstruire contre openssl (au lieu de NSS) qui devrait fonctionner. (4) configuré stunnel(qui utilise openssl) en tant que plain-to-SSL, indiquez curl http(notS)://localhost[:port]/whatevermais ajoutez-le -H "Host: realhost"afin que le serveur cible ne puisse pas faire la différence. ...
dave_thompson_085
1
... (5) similaire mais plus officiel: configurez un vrai proxy HTTP en utilisant openssl ici, ou tout SSL / TLS compatible TLS1.2-ECDHE sur un autre système sous votre contrôle, peut-être même une VM sur votre machine réelle, comme HAproxy ou nginx ou même httpd, auquel vous vous connectez avec HTTP simple ou au moins non-ECDHE HTTPS mais reliez au serveur réel avec un bon ECDHE HTTPS.
dave_thompson_085
1
NSS en amont prend définitivement en charge ECDHE depuis longtemps. RedHat depuis des années jusqu'à la fin de 2014 a supprimé (toutes les variantes de) ECC de leurs versions de packages de chiffrement (AFAIK all, définitivement OpenSSL NSS OpenJDK) pour de vagues raisons `` juridiques '', que j'ai appelé ci-dessus `` long déni ''. Je suppose que quand ils l'ont remis, ils ont fait une erreur probablement mineure en affectant ce cas curl / NSS. Je ne connais aucune autre distribution qui a fait cela, mais il y en a beaucoup et quelqu'un pourrait; dans celui que j'ai actuellement Ubuntu, 14.04LTS Trusty, curl utilise OpenSSL et prend en charge ECDHE.
dave_thompson_085

Réponses:

8

La solution était mise à niveau vers cURL 7.42 à l'aide d'un référentiel tiers pour CentOS 6 ou à partir de sources

Marco Marsala
la source
14
La mise à niveau du package nss (ie yum update nss) ou l'utilisation curl -1pourrait également résoudre ce problème.
DiegoG
1
Merci! J'ai rencontré ce problème car le serveur nécessite tlsv1.2. La mise à niveau a résolu mon problème.
hao
la mise à jour du nss consiste à résoudre ce problème
Sơn Lâm
4

Nous avons eu le même problème avec curl 7.19.7. Nous avons mis à niveau NSS et cela a résolu le problème!

Jacob Klein
la source
0

Sur CentOS 6 avec le dernier paquet openssl (1.0.1e) Vous devez mettre à jour nss (yum update nss) comme DiegoG l'a écrit ci-dessus. La commande update-ca-trust peut également être utile. Si vous utilisez curl via php - redémarrez votre processus / service de serveur Web (c.-à-d. Service httpd restart).

userK
la source