Holas!
Quería compartir una vulnerabilidad que Nessus de momento pasa por alto. Por poner en contexto, cuando en un servidor ssl/tls remoto se identifica DES/3DES, se marca como vulnerable a “sweet32”, igual pasa con RC4 “Bar mitzvah”. (nessus way)
Bien, nmap añadió hace no mucho una comprobación en su script –ssl-enum-ciphers que nos muestra el siguiente warning (comprobar en captura adjunta):
- “Key Exchange (dh 1024) of lower strength than certificate key”
Qué quiere decir esto? Nmap a través del script le muestra al servidor remoto todos las modalidades de DH (“Diffie-Hellmann”) que podría aceptar, y de todas ellas, ha escogido la más débil (1024). Teniendo en cuenta que el certificado en este caso tiene una clave RSA de 2048 bits, la solución global está negociando una conexión más débil de que podría.
A qué se debe y qué solución tiene?
Esta vulnerabilidad se debe a que en este caso el servidor auditado es un Nginx (aunque da igual con Apache también), ambos confían en OpenSSL instalado en la máquina GNU\Linux para gestionar la criptografía de los servidores web. Y OpenSSL, por defecto, negocia DH a 1024, por lo que para solucionarlo debemos regenerar parámetros DHE de mayor fortaleza:
- cd /etc/ssl/certs
- openssl dhparam –out dhparam.pem 4096
- Posteriormente, es necesario instar a Nginx a que use esta nueva configuración a través de la siguiente directiva en /etc/nginx/nginx.conf:
- ssl_dhparam /etc/ssl/certs/dhparam.pem;