Implementación de la Secreto Perfecto de Avance SSL en el Servidor Web NGINX

Este CÓMO describe el proceso de implementación de Secreto Perfecto de Avance con el servidor web NGINX en sistemas Debian y Ubuntu. El proceso se puede adaptar fácilmente a otros sistemas GNU/Linux.

En resumen, el Secreto Perfecto de Avance asegura: “… que el compromiso de un mensaje no puede llevar al compromiso de otros, y también que no hay un único valor secreto que pueda llevar al compromiso de múltiples mensajes.” Para más información, consulte http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Cuando se reveló la vulnerabilidad Heartbleed en OpenSSL a principios de 2014, se hizo cada vez más claro que PFS es imprescindible para cualquier sistema que emplee SSL/TLS de manera seria.

Si desea comparar sus resultados con los míos, mi implementación de referencia se puede probar en https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org, y la cadena de certificados SSL y los encabezados de NGINX que se envían se pueden revisar en https://indietorrent.org.

Sin más preámbulos, configuremos NGINX para implementar PFS.

Pasemos al directorio de configuración de NGINX:

cd /etc/nginx/

Necesitamos generar parámetros de Diffie-Hellman que sean suficientemente fuertes. Algunos argumentan que 4096 bits es excesivo y causará una carga indebida en la CPU del sistema, pero con el poder de computación moderno, parece un compromiso que vale la pena. Para más información, consulte la sección de Referencias, a continuación.

openssl dhparam -out dh4096.pem 4096

Es útil tener este archivo de configuración, que es específico para la tarea en cuestión, compartimentado en un archivo de inclusión; esto facilita la implementación de PFS en un gran número de sistemas.

vi /etc/nginx/perfect-forward-secrecy.conf

Pegue lo siguiente en el archivo anterior:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

Modifique la configuración de NGINX para incluir el archivo anterior, insertando la siguiente línea en el archivo de configuración principal de NGINX (por defecto, /etc/nginx/nginx.conf), en la parte inferior de (y dentro de) el bloque http {}:

# Ver: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# Esto DEBE venir DESPUÉS de las líneas que incluyen .../sites-enabled/*, de lo contrario, el soporte para SSLv3 puede ser reactivado accidentalmente.
include perfect-forward-secrecy.conf;

Reinicie NGINX para hacer efectivas los cambios:

service nginx restart

Si la prueba en https://www.ssllabs.com/ssltest/analyze.html muestra Reanudación de sesión (caché) No (IDs asignados pero no aceptados) en rojo, y el servidor implementa SNI, agregue lo siguiente al bloque http {} de nivel superior (es decir, agregue a nginx.conf, justo debajo de donde hicimos las adiciones anteriores):

# Ver: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Nuevamente, reinicie NGINX para hacer efectivas los cambios:

service nginx restart

La prueba anterior ya no debería informar este problema (aunque el problema no reduce la puntuación general de la prueba).

Llevándolo Más Allá: Implementación de HTTP Strict Transport Security (HSTS) con Larga Duración

Este es fácil, y vale la pena hacerlo, siempre que:

1. Desea forzar SSL para todos los recursos de cualquier host para el cual se establece este encabezado (es decir, cada página en el sitio web en cuestión).
2. Puede vivir sin tener la capacidad de aceptar e ignorar advertencias de SSL para cualquier recurso solicitado de cualquier host para el cual se establece este encabezado, como “Desajuste de Nombre de Dominio”, etc. La naturaleza misma de HSTS es que las condiciones de advertencia y error relacionadas con el certificado SSL no pueden ser anuladas.

Busqué en Internet información sobre si establecer este encabezado podría tener consecuencias no deseadas en navegadores que no lo soportan y no encontré nada. Pero, pude calmar mis preocupaciones probando esta implementación en Internet Explorer 6, por ejemplo, y los navegadores en los que HSTS no está implementado simplemente ignoran el encabezado. ¡Perfecto!

Simplemente agregue las siguientes líneas al final de /etc/nginx/perfect-forward-secrecy.conf y guarde los cambios:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# Esto evitará ciertos ataques de click-jacking, pero evitará
# que otros sitios enmarquen su sitio, así que elimine o modifique según sea necesario.
add_header X-Frame-Options SAMEORIGIN;

Una recarga (en lugar de un reinicio) será suficiente para forzar a NGINX a recoger estos cambios particulares:

service nginx reload

Es posible confirmar que HSTS está funcionando como se esperaba probando su implementación en https://www.ssllabs.com/ssltest/analyze.html. Si HSTS está implementado correctamente, debería ver un cuadro verde justo debajo de su puntuación, indicando: “Este servidor soporta HTTP Strict Transport Security con larga duración. Grado establecido en A+.”

¡Felicidades!

Ahora tiene una de las implementaciones de SSL/TLS más seguras en Internet.

Referencias:

• https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Copyright © 2014 Ben Johnson