Ricevo un errore NSS error -12286durante il download di un file da HTTPS utilizzando curl.
Posso scaricare lo stesso file senza problemi in wgetmodo da poter escludere eventuali problemi di firewall o blacklist.
Già provato, senza fortuna, opzioni -ke --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, ovvero la cifra preferita dal server secondo lo strumento Qualys SSL Labs Test Server qui: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest
Ecco il cURLregistro:
# 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
Le mie versioni lib sono:
# 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
Posso riprodurre il tuo problema con CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 su un server di prova. Per impostazione predefinita, non offre alcuna suite ECC e poiché il tuo server (Cloudfare) accetta solo alcune negoziazioni di suite ECC (in particolare ECDHE) non riesce. Con
—
dave_thompson_085,
--cipher[s]specificando che privato ECDHE, non ha nemmeno inviare ClientHello, appena chiude la connessione e dà l'errore. Questo sembra essere qualcosa fuori sincrono internamente, forse dopo la lunga negazione di ECC da parte di RedHat. RedHat wget utilizza OpenSSL e RedHat OpenSSL recente supporta ECC (solo con P256 P384 P521 ma qui è abbastanza).
La mia prima scelta sarebbe (0) non usare (this) curl, ma se vuoi davvero che le opzioni che vedo siano: (1) se hai supporto, segnalalo come un bug e spero che lo risolvano. (2) è open source; eseguire il debug e risolverlo da soli. (3) è open source; ricostruire contro openssl (anziché NSS) che dovrebbe funzionare. (4) impostare
—
dave_thompson_085,
stunnel(che utilizza openssl) come da semplice a SSL, dire curl http(notS)://localhost[:port]/whateverma aggiungere in -H "Host: realhost"modo che il server di destinazione non possa distinguere. ...
... (5) simile ma più ufficiale: imposta un vero proxy HTTP usando openssl qui, o qualsiasi SSL / TLS compatibile con TLS1.2-ECDHE su un altro sistema nel tuo controllo forse anche una VM sulla tua macchina reale, come HAproxy o nginx o persino httpd, a cui ti connetti con HTTP semplice o almeno non ECDHE HTTPS ma inoltra al server reale con un buon HTTPS ECDHE.
—
dave_thompson_085,
NSS upstream supporta sicuramente ECDHE per molto tempo. RedHat per anni fino alla fine del 2014 ha rimosso (tutte le varianti di) ECC dalle loro build di pacchetti crittografici (tutti AFAIK, sicuramente OpenSSL NSS OpenJDK) per vaghi motivi "legali", che sopra ho chiamato "lunga negazione". Immagino che quando lo hanno rimesso hanno commesso un errore probabilmente minore sul caso curl / NSS. Non conosco altre distro che hanno fatto questo, ma ce ne sono molte e qualcuno potrebbe; in quello che attualmente ho Ubuntu, 14.04LTS Trusty, curl usa OpenSSL e supporta ECDHE.
—
dave_thompson_085,
SSL_ERROR_NO_CYPHER_OVERLAP"Impossibile comunicare in modo sicuro con il peer: nessun algoritmo di crittografia comune." I sistemi locale e remoto non condividono suite di cifratura in comune. Ciò può essere dovuto a un'errata configurazione alle due estremità. Può essere dovuto alla configurazione errata di un server per l'utilizzo di un certificato non RSA con l'algoritmo di scambio delle chiavi RSA.