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
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
—
dave_thompson_085
--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).
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é
—
dave_thompson_085
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. ...
... (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
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
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.