ssl_ciphers recomendados para seguridad, compatibilidad - secreto perfecto hacia adelante

Primero, veamos cómo funciona la negociación de la suite de cifrado, muy brevemente. Por ejemplo, podemos usar el documento TLS 1.2 RFC 5246 comenzando en la sección 7.4.1.2 para ver , en la forma corta y corta:

• ClientHello: el cliente le dice al servidor qué conjuntos de cifrado admite el cliente
• Ahora el servidor escoge uno
  • ¡Discutiré cómo controlar cuál elige a continuación!
• ServerHello: el servidor le dice al cliente qué conjunto de cifrado ha elegido, o le da un mensaje de error al cliente.

Ahora, en cuanto a la selección real. He utilizado la documentación del módulo nginx ssl , la comunidad Qualys 2013 artículo sobre la configuración de Apache, Nginx y OpenSSL para el secreto de seguridad , y el artículo Hynek Hardening SSL Web Ciphers como referencia. Los dos últimos cubren tanto Apache como Nginx (ya que ambos usan OpenSSL como base).

Esencialmente, debe decirle a Nginx que use el orden que seleccione, y necesita seleccionar un pedido. Para ver cuáles serían los resultados de ese orden, puede usar la línea de comandos de OpenSSL, por ejemplo,

openssl ciphers -v 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EDH+aRSA+AESGCM:EDH+aRSA+SHA256:EDH+aRSA:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED'

NOTA: Es posible que desee eliminar:! 3DES de esa cadena; El triple DES de 3 teclas no es eficiente, pero sigue siendo seguro en sí mismo con más o menos 112 bits de seguridad, y es muy, muy común.

Use el comando anterior para determinar qué conjuntos de cifrado serán los más preferidos y los menos preferidos en su configuración, y modifíquelos hasta que le gusten los resultados. Las referencias que he dado tienen sus propias cadenas; Lo modifiqué ligeramente para obtener el ejemplo anterior (eliminando RC4 y SEED, y poniendo cada conjunto de cifrado TLS 1.2 por encima de cualquier conjunto de cifrado 'SSLv3', por ejemplo).

Luego, para Nginx en particular, alteraría su archivo de configuración para incluir algo como:

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

Agregue SSLv3 a ssl_protocols si realmente insiste en ello.

ssl_prefer_server_ciphers informará a nginx para usar el orden que especificamos e ignorará el orden en el que el cliente presenta su lista de cifrado. Ahora, si el único conjunto de cifrado compartido entre ClientHello y la lista OpenSSL ciphers -v ... muestra Nuestro cifrado menos preferido es, por supuesto, lo que usará nginx. Si nada coincide, entonces enviamos al cliente un aviso de falla.

El comando ssl_ciphers es la fuente de la elección, aquí, como nginx informará a OpenSSL de nuestra lista de conjuntos de cifrado preferidos. Por favor, use el comando openssl ciphers -v para ver los resultados que obtiene en su plataforma. Lo ideal es volver a comprobarlo después de cambiar las versiones de OpenSSL.

También, lea Artículo de Scott Helme sobre Configuración de HSTS (Seguridad de transporte estricta de HTTP) en nginx , que permitirá a un host hacer cumplir el uso de HTTPS en el lado del cliente. Asegúrese de incluir el encabezado HSTS dentro del bloque http con la declaración de escucha ssl.

Editado para agregar: al menos después de esto (si no antes también), vaya a Qualys SSL Labs para ver la información de seguridad de HTTPS y a Pruebe su servidor que se ha mantenido bastante actualizado durante los últimos años. Las recomendaciones cambian regularmente y, a veces, incluso se revierten con frecuencia (RC4, por ejemplo, lo que casi induce al latigazo). ¡También puedes incluso Prueba tu navegador !

Mozilla tiene una herramienta en línea que le ayudará a elegir el conjunto de cifrado correcto.

enlace

Le permitirá ingresar la versión de su servidor, la versión de software, etc. y luego elegir entre un equilibrio de seguridad y soporte heredado.

Por lo general, OpenSSL preferirá los nuevos MAC para las suites de cifrado equivalentes . Por ejemplo, la salida larga de openssl ciphers -v para su cadena de cifrado comienza con:

ECDHE-RSA-AES256-GCM-SHA384    TLSv1.2  Kx=ECDH        Au=RSA    Enc=AESGCM(256)    Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384  TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AESGCM(256)    Mac=AEAD
ECDHE-RSA-AES256-SHA384        TLSv1.2  Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA384
ECDHE-ECDSA-AES256-SHA384      TLSv1.2  Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA384
ECDHE-RSA-AES256-SHA           SSLv3    Kx=ECDH        Au=RSA    Enc=AES(256)       Mac=SHA1
ECDHE-ECDSA-AES256-SHA         SSLv3    Kx=ECDH        Au=ECDSA  Enc=AES(256)       Mac=SHA1

Por supuesto, TLS solo usará suites de cifrado compatibles entre sí por el servidor y el cliente, y ni Chrome ni Firefox son compatibles con las suites de cifrado HMAC-SHA256. Dado que HMAC-SHA1 (e incluso HMAC-MD5) aún se consideran seguros, creo que sus desarrolladores (y los de NSS, la biblioteca TLS que ambos usan) se muestran escépticos de perder el esfuerzo de los desarrolladores y el tamaño del protocolo de enlace TLS añadiendo nuevos, innecesarios y anteriores - suites de cifrado incompatibles.

Mira, por ejemplo, suites de cifrado compatibles con Chrome 33 en orden de preferencia :

1. ChaCha20-Poly1305 ,
2. AES-128-GCM,
3. AES-256-CBC con HMAC-SHA1,
4. RC4 (ugh) y AES-128-CBC con HMAC-SHA1, ...

OpenSSL no admite ChaCha20-Poly1305. Si el suyo no es compatible con AES-GCM (???) y utiliza un certificado RSA, ECDHE-RSA-AES256-SHA es, naturalmente, el conjunto de cifrado que Chrome utilizará. (Firefox 29 usaría ECDHE-RSA-AES128-SHA .)

(Las suites de cifrado "SHA-256" que ha visto que se usan en otros sitios web son probablemente ChaCha20-Poly1305 o AES-128-GCM, que son AEADs que no hace uso de HMAC, pero cuyos conjuntos de cifrado usan SHA-256 en la PRF .)

para una mejor compatibilidad, la suite de cifrado de nube no es la mejor; Encontré mejor lo siguiente:

# suggestion from sslabs / including PFS, good compatibility
#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;


# suggestion my mozilla-server-team - good compatibility, pfs
#ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK;

cuando verifique cada configuración con ssllabs encontrará para esas 2 suites la siguiente declaración:

• Secreto de reenvío Sí (con la mayoría de los navegadores) ROBUSTO

mientras que en su cipher_suite sugerido dice:

• Secreto hacia adelante Sí (con navegadores modernos)

información adicional: Guide to Nginx + SSL + SPDY

La recomendación de Comodo es:

ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";

Fuente: enlace

enlace es otro sitio que ofrece:

  

Los cifrados anteriores se pueden copiar en su nginx, Lighttpd o Apache config. Estos proporcionan una fuerte seguridad SSL para todos los navegadores modernos, además de obtener una A + en la prueba de laboratorio de SSL.

Este material está desactualizado todo el tiempo, pero para su valor, en mayo de 2018, aquí están sus recomendaciones para nginx:

ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_prefer_server_ciphers on; 
ssl_dhparam /etc/nginx/dhparam.pem; # openssl dhparam -out /etc/nginx/dhparam.pem 4096
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;
ssl_ecdh_curve secp384r1; # Requires nginx >= 1.1.0
ssl_session_timeout  10m;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off; # Requires nginx >= 1.5.9
ssl_stapling on; # Requires nginx >= 1.3.7
ssl_stapling_verify on; # Requires nginx => 1.3.7

La elección de la función hash (SHA-1 vs SHA-256) no depende realmente del conjunto de cifrado , sino de la versión del protocolo . Básicamente, obtienes SHA-256 si usas TLS 1.2 , SHA-1 si usas una versión anterior.

(Sí, sé que esto es una descripción simplificada de una situación un poco más compleja, pero aquí funciona).

Normalmente, el cliente y el servidor utilizarán la versión de protocolo más alta que ambos admiten, por lo que ya debería obtener TLS-1.2 (por lo tanto, SHA-256) siempre que sea posible. Tenga en cuenta que esto requiere que tanto el código del servidor (OpenSSL) como el código del cliente sean recientes. Puede modificar ese mecanismo explícitamente con ssl_protocols .