cURL no se conecta a HTTPS mientras que wget sí (error NSS -12286)

8

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
curl nss Marco Marsala
fuente
Relevante: www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/… donde dice que el error NSS -12286 significa 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.
Celada
2
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 --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í).
dave_thompson_085
1
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 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. ...
dave_thompson_085
1
... (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
1
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

Respuestas:

8

La solución fue actualizar a cURL 7.42 utilizando un repositorio de terceros para CentOS 6 o compilando desde fuentes

Marco Marsala
fuente
14
Actualizar el paquete nss (es decir yum update nss) o usarlo curl -1también podría resolver esto.
DiegoG
1
¡Gracias! Encontré este problema porque el servidor requiere tlsv1.2. La actualización resolvió mi problema.
Hao
actualizar el nss es solucionar ese problema
Sơn Lâm
4

Tuvimos el mismo problema con curl 7.19.7. ¡Actualizamos NSS y solucionó el problema!

Jacob Klein
fuente
0

En CentOS 6 con el último paquete openssl (1.0.1e) Debe actualizar nss (yum update nss) como DiegoG escribió anteriormente. El comando update-ca-trust también puede ser útil. Si está utilizando curl a través de php, reinicie el proceso / servicio del servidor web (es decir, el servicio httpd restart).

usuarioK
fuente