¿Debe persistir el valor de un grupo Diffie-Hellman?

1

He estado leyendo sobre el ataque de Logjam en Diffie-Hellman y sobre cómo proteger nuestros servidores web basados en TLC según los hallazgos recientes.

La guía sugiere que creemos un grupo Unique Diffie-Hellman. Como entiendo el protocolo, este grupo debe ser el mismo para una sola conexión TLS. Es decir, desde la perspectiva del protocolo, el grupo podría generarse cada vez que se realiza una nueva conexión TLS, incluso para el mismo cliente. (Aunque el tiempo de cómputo y los recursos necesarios para crear un nuevo primo lo harían poco práctico).

Quiero estar seguro de las implicaciones de esto.

  1. No es necesario que persista el grupo generado. Si el servidor muere y el grupo muere con él, no hay pérdida.
  2. Los diferentes subdominios pueden tener diferentes grupos, incluso cuando se usa un certificado comodín.
  3. Los navegadores no avisarán a los usuarios de cambios en este grupo.
pregunta David V 29.05.2015 - 18:18
fuente

2 respuestas

2

Tus inferencias son correctas; de hecho, a menudo se expresan a la inversa: mientras que cada instancia (protocolo de enlace TLS) utiliza su propio grupo, es posible reutilizar el mismo grupo entre instancias, independientemente de si son para el mismo servidor o un servidor distinto. Todo el negocio de Logjam era sobre clientes y servidores que usaban un grupo débil (porque el módulo era demasiado corto); La reutilización de ese grupo por parte de muchos servidores simplemente extendió el alcance del ataque.

No hay ninguna relación entre el grupo y el certificado o dominio; el servidor envía los parámetros de grupo para cada saludo, de modo que los clientes no necesitan recordar nada sobre ese grupo y, en la práctica, los clientes no intentan recordar nada sobre el grupo, por lo que no harán nada especial si un grupo determinado se reutiliza o no se reutiliza.

Sin embargo , hay que tener en cuenta que la generación de grupos es algo cara. No es necesariamente tan largo como lo que hace OpenSSL, porque OpenSSL insiste en usar una "prima segura", que es una exageración aquí (y, posiblemente, no es "más segura" de ninguna manera que una prima no segura, porque la terminología es meramente tradicional). Sin embargo, producir un nuevo grupo sigue siendo una cuestión de unos pocos segundos de CPU, por lo que no desea hacerlo para cada conexión entrante. Lo que se podría hacer es generar nuevos parámetros DH al iniciar el servidor, por lo tanto, los parámetros no deberían guardarse en ningún archivo.

Pragmáticamente, los servidores web existentes (por ejemplo, Apache) pueden leer los parámetros de un archivo, y la guía que vincula con los defensores de la generación de un grupo DH único para su servidor . El valor principal para generar su propio grupo es que le permite generar un grupo strong , es decir, con un módulo lo suficientemente grande. Que el grupo no sea compartido por otros servidores es solo de importancia secundaria.

Tenga en cuenta que para curvas elípticas , todos trabajan con el mismo grupo (es decir, la misma curva), porque las implementaciones desplegadas están especializadas para esa curva específica (*) y no pueden manejar ninguna otra. Si la reutilización del grupo era realmente un problema, las curvas elípticas tendrían que desactivarse lo antes posible. Afortunadamente, la reutilización no es un problema.

(*) En realidad, dos curvas, P-256 y P-384 de NIST, que forman parte de NSA Suite B ; por algún motivo, los proveedores de navegadores consideran a esta suite como una especie de evangelio, que debe seguirse en la letra; de lo contrario, los dioses lo golpearán con un rayo.

    
respondido por el Tom Leek 29.05.2015 - 19:30
fuente
0

Corregir en todas las cuentas. El grupo específico que se utiliza no tiene nada que ver con la identidad del servidor (o del usuario) y se puede cambiar en cualquier momento.

Un grupo de 2048 bits debería ser adecuado por ahora, y si tiene su propio grupo único, es extremadamente improbable que alguien utilice los recursos para realizar todos los cálculos previos necesarios para atacarlo, incluso cuando las computadoras se vuelven lo suficientemente rápidas. Ese 2048 bits es factible. Será un ataque muy costoso por mucho tiempo.

Así que no hay necesidad de cambiarlo una vez que lo hayas creado, pero si necesitas regenerarlo por alguna razón, no hay daño.

SRP es un protocolo de estilo DH autenticado por contraseña, y con eso no querría cambiar los parámetros del grupo, ya que hacerlo invalidaría los verificadores para todos los usuarios (por lo que sus contraseñas no funcionarán). No es así como funciona DH (donde normalmente solo se autentica el servidor, utilizando otro mecanismo independiente del grupo DH).

    
respondido por el Steve Peltz 29.05.2015 - 18:36
fuente

Lea otras preguntas en las etiquetas