Recibo un error NSS error -12286al descargar un archivo desde HTTPS usando curl.
Puedo descargar el mismo archivo sin problemas, por wgetlo que puedo excluir cualquier problema de firewall o lista negra.
Ya probé, sin suerte, las opciones -ky --cipher ecdhe_ecdsa_aes_128_gcm_sha_256, ese es el cifrado preferido del servidor de acuerdo con la herramienta Qualys SSL Labs Test Server aquí: https://www.ssllabs.com/ssltest/analyze.html?d=intribunale.net&latest
Aquí está el 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
Mis versiones lib son:
# 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
Puedo reproducir su problema con CentOS6.7 curl-7.19.7-46.el6 nss-3.21.0-0.3.el6_7 en un servidor de prueba. Por defecto, no ofrece ninguna suite ECC, y dado que su servidor (Cloudfare) solo acepta ciertas suites ECC (específicamente ECDHE), la negociación falla. Al
—
dave_thompson_085
--cipher[s]especificar esa suite ECDHE, ni siquiera envía ClientHello, solo cierra la conexión y da el error. Esto parece estar fuera de sincronización internamente, tal vez después de la larga negación de ECC por parte de RedHat. RedHat wget usa OpenSSL, y RedHat OpenSSL reciente es compatible con ECC (solo con P256 P384 P521 pero eso es suficiente aquí).
Mi primera opción sería (0) no usar (este) curl, pero si realmente quieres las opciones que veo son: (1) si tienes soporte, infórmalo como un error y espero que lo solucionen. (2) es de código abierto; depurar y arreglarlo usted mismo. (3) es de código abierto; reconstruir contra openssl (en lugar de NSS) que debería funcionar. (4) configurar
—
dave_thompson_085
stunnel(que usa openssl) como simple a SSL, decirle a curl http(notS)://localhost[:port]/whateverpero agregar -H "Host: realhost"para que el servidor de destino no pueda notar la diferencia. ...
... (5) similar pero más oficial: configure un proxy HTTP real usando openssl aquí, o cualquier SSL / TLS compatible con TLS1.2-ECDHE en otro sistema bajo su control, tal vez incluso una VM en su máquina real, como HAproxy o nginx o incluso httpd, al que se conecta con HTTP simple o al menos HTTPS no ECDHE, pero se transmite al servidor real con un buen HTTPS ECDHE.
—
dave_thompson_085
NSS upstream definitivamente es compatible con ECDHE durante mucho tiempo. RedHat durante años hasta finales de 2014 eliminó (todas las variantes de) ECC de sus compilaciones de paquetes de cifrado (AFAIK all, definitivamente OpenSSL NSS OpenJDK) por vagas razones 'legales', que anteriormente llamé 'larga negación'. Supongo que cuando lo volvieron a colocar cometieron un error probablemente menor que afecta este caso curl / NSS. No conozco ninguna otra distribución que haya hecho esto, pero hay muchas y alguien podría; en el único Ubuntu que tengo actualmente, 14.04LTS Trusty, curl usa OpenSSL y admite ECDHE.
—
dave_thompson_085
SSL_ERROR_NO_CYPHER_OVERLAP"No se puede comunicar de forma segura con un par: no hay algoritmos de cifrado comunes". Los sistemas locales y remotos no comparten conjuntos de cifrado en común. Esto puede deberse a una configuración incorrecta en cualquiera de los extremos. Puede deberse a que un servidor esté mal configurado para usar un certificado que no sea RSA con el algoritmo de intercambio de claves RSA.