En una revisión con fecha 2016-10-31 , Mozilla cambió su recomendación Server Side TLS de generar un grupo DH aleatorio a los publicados en RFC 7919 . Mozilla afirma:
Estos grupos son auditados y pueden ser más resistentes a los ataques que los generados aleatoriamente.
¿No está utilizando un grupo DH publicado algo Logjam desaconsejado?
Creo que la razón para usar grupos predefinidos se responde claramente en la página a la que hace referencia:
En lugar de usar grupos DH preconfigurados, o generar su propio grupo con "openssl dhparam", los operadores deben usar los grupos DH predefinidos ffdhe2048, ffdhe3072 o ffdhe4096 recomendados por el IETF en RFC 7919 . Estos grupos son auditados y pueden ser más resistentes a los ataques que los generados aleatoriamente.
En la conexión con el ataque Logjam, se recomendó no utilizar grupos DH predefinidos con 1024 bits o menos, ya que este tamaño de clave se considera que está al alcance de los atacantes de hoy en día y podría valer la pena el esfuerzo de las claves muy utilizadas. Pero los tamaños de clave más grandes aún no se consideran al alcance de los atacantes.
Creo que la idea detrás de RFC 7919 fue más sobre la interoperabilidad.
Mientras que un servidor del grupo DH personalizado es potencialmente más seguro y no se verá afectado si, por ejemplo, La NSA logra descifrar uno de los grupos más comúnmente utilizados, pone esfuerzo de comprobación de cordura EN EL CLIENTE. Y estos clientes pueden tener ideas muy diferentes sobre lo que constituye un grupo sano y seguro. Podrían tener diferentes ideas sobre la longitud de bits aceptable, por ejemplo. Y no había canal de vuelta. El cliente no tenía forma de decirle al servidor por adelantado "Aceptaré tales y a tales grupos ..." y después no le diré al servidor "Lo siento, no trabajaré con ese grupo! " El cliente simplemente fallaría y el servidor nunca lo supo. Pesadilla de interoperabilidad.
Ahora, lo que RFC7919 intenta hacer es usar la misma lógica que ya existe para la curva elíptica DH y usarla para regular ("MODP", "campo finito") DH.
De esa manera, el cliente al menos puede decir por adelantado "Aceptaré tales y tales grupos ..." y el puñado de grupos que forman parte de IANA group register puede ser revisado / examinado por el público.
El RFCs Abstract enumera las razones:
Resumen
Intercambio de clave Diffie-Hellman (DH) tradicional basado en campo finito durante el protocolo de seguridad de la capa de transporte (TLS), el protocolo de enlace sufre Número de deficiencias de seguridad, interoperabilidad y eficiencia. Estas deficiencias surgen de la falta de claridad sobre qué grupo DH Los parámetros que deben ofrecer los servidores TLS y los clientes deben aceptar. Esta El documento ofrece una solución a estas deficiencias para los compañeros compatibles. mediante el uso de una sección del "Registro de grupos admitidos" de TLS (renombrado del "Registro de Curva Nombrado CE" por este documento) para establecer Parámetros de campo finito DH con estructura conocida y un mecanismo para compañeros para negociar el apoyo a estos grupos.
Este documento actualiza las versiones TLS 1.0 (RFC 2246), 1.1 (RFC 4346), y 1.2 (RFC 5246), así como la criptografía de curva elíptica TLS (ECC) extensiones (RFC 4492).
Acabo de encontrar este documento:
En el resumen, dicen que los clientes normalmente no verifican los parámetros en tiempo de ejecución debido a los impactos en el rendimiento.
Por lo tanto, aquí tiene sentido definir, comprobar la cordura y nombrar algunos grupos DH de campo finito. (Al menos tiene más sentido que no verificar nada).
Lea otras preguntas en las etiquetas tls diffie-hellman logjam