¿Hay algún beneficio de seguridad al implementar grupos DH de SSH personalizados en sistemas solo para clientes?

16

Una estrategia mitigante sugerida contra los ataques relacionados con Logjam en SSH es generar grupos SSH Diffie-Hellman personalizados usando algo como (el siguiente es para OpenSSH)

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

seguido de reemplazar el archivo de módulo de todo el sistema con el archivo de salida moduli-2048. ( ssh-keygen -Gse utiliza para generar candidatos DH-GEX primos y ssh-keygen -Tpara probar los candidatos generados por seguridad).

Esto es claramente algo razonable de hacer en servidores SSH que de otro modo estarían usando grupos conocidos que se prestan bien a la precomputación, pero ¿hay algún beneficio de seguridad al implementar grupos SSH DH personalizados en sistemas solo para clientes? (Es decir, sistemas que se conectan a servidores SSH, pero nunca actúan como un servidor SSH).

Estoy principalmente interesado en respuestas relacionadas con OpenSSH en Linux, pero también agradecería respuestas más genéricas.

ssh ssh-keys logjam

— un CVn
fuente

18

Puede hacerlo si realmente quiere, pero no me molestaría en regenerar parámetros DH de 2048 bits para OpenSSH. Hay cosas mucho más importantes que debe hacer para asegurar SSH, como deshabilitar la criptografía débil .

Lo que haría es eliminar los existentes que tienen menos de 2048 bits.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

En caso de que no lo haya notado, OpenSSH se envía con una gran cantidad de módulos pregenerados, hasta 8192 bits. Si bien estamos preocupados por los primos de 1024 bits hoy, se cree que los de 2048 bits son seguros en el futuro previsible. Y aunque eso eventualmente cambiará, podría ser la próxima semana, pero es más probable que pase mucho tiempo después de que nos hayamos convertido en pensionistas ...

También hay esta parte curiosa en la ssh-keygenpágina del manual:

Es importante que este archivo contenga módulos de un rango de longitudes de bits y que ambos extremos de una conexión compartan módulos comunes.

Lo que parece argumentar en contra de reemplazar los módulos existentes, aunque en realidad no proporciona la razón real para hacerlo.

— Michael Hampton
fuente

Relacionado: Diffie-Hellman usando un módulo diferente en ambos lados en Criptografía . A mi entender limitado, parece que si no hay módulos compartidos de una longitud deseada, Diffie-Hellman con un grupo de esa longitud no es posible en el caso general, y podría no ser posible en ningún caso específico. Por lo tanto, tener módulos compartidos entre los dos puntos finales es un requisito matemático del protocolo de intercambio de claves Diffie-Hellman, e intentar realizar un intercambio de claves Diffie-Hellman entre dos puntos finales que no tienen módulos comunes fallará.

— un CVn

2

RFC 4419 [ tools.ietf.org/html/rfc4419] es precisamente para permitir que el servidor proporcione parámetros DH personalizados. El servidor envía sus parámetros candidatos al cliente, y si el cliente está de acuerdo, ambas partes usan los parámetros proporcionados por el servidor para generar un secreto compartido que se usa como clave de sesión. Por lo tanto, está perfectamente bien si el servidor y el cliente no tienen las mismas entradas en su archivo de módulos.

— Brian Minton

2

La respuesta es: No. No hay beneficios. :)

/etc/ssh/moduli El archivo solo se utiliza para el lado del servidor.

No necesita preocuparse por ese archivo para el lado del cliente SSH:

Puede rastrear la ejecución del cliente SSH y verificar que no abra ese archivo.

$ strace -e openat ssh user@localhost

— Adi Roiban
fuente