Grupo DH compartido, secretos nuevos: por qué el ataque sale más barato

Los parámetros del grupo son públicos por diseño, y esa publicidad es justo lo que los hace fáciles de pasar por alto. En Diffie-Hellman de campo finito el módulo y el generador son compartidos, mientras que los exponentes privados y las claves de sesión resultantes no lo son. La fase cara de un ataque con criba de campo de números depende del grupo y no de un solo intercambio, así que un único grupo débil usado en todas partes se convierte en una responsabilidad compartida. Llamar públicos a los parámetros es exacto y no viene al caso, porque el coste que se reutiliza es el coste de atacar ese grupo.

La mitad pública no es la mitad vulnerable, y ahí está la trampa

El habitual medio argumento dice que los parámetros se publican en una norma, así que un atacante ya los conoce y ocultarlos no cambiaría nada. Ambas afirmaciones son ciertas y ninguna se deduce de la otra. Un grupo predeterminado enviado es público, y un grupo privado que usted generó la semana pasada también es visible para cualquiera que complete el handshake. El secreto nunca fue el control; lo son la fuerza y la validación.

Lo que sí cambia es cuántos sitios comparten la misma debilidad. Una organización que genera su propio grupo de 2048 bits paga su propio coste de ataque, mientras que un valor predeterminado de protocolo elegido por millones amortiza un solo coste entre todos ellos. Es en ese sentido en el que un grupo poco común no es automáticamente mejor. Un grupo poco habitual que es demasiado pequeño no es más que un secreto compartido más pequeño con menos ojos encima.

La validación importa tanto como el tamaño. Un par que envía un módulo con factores pequeños, o uno que no tiene la forma que el protocolo espera, puede filtrar información sobre el exponente privado incluso cuando la longitud en bits parece respetable. Las bibliotecas que rechazan parámetros mal formados a la entrada hacen trabajo real, y por eso el análisis de parámetros hecho a mano es un mal lugar donde ahorrar esfuerzo.

Qué compra realmente el precálculo a un atacante

La criba de campo de números tiene una fase que depende solo del número primo, y su salida es reutilizable contra cada intercambio que usa ese primo. Ese es todo el mecanismo detrás de la preocupación histórica: la parte cara se paga una vez y el coste marginal de cada sesión posterior baja. Los exponentes nuevos aún protegen cada intercambio individual de un observador pasivo, siempre que el grupo sea lo bastante grande para hacer la criba inviable. Las dos afirmaciones son compatibles, y la mayoría de las discusiones sobre este tema vienen de escoger una y descartar la otra.

El trabajo de Logjam de 2015 demostró una degradación a Diffie-Hellman de 512 bits de grado exportación y estimó lo que costaría atacar grupos mayores y muy reutilizados con recursos significativos. La demostración era concreta, las estimaciones eran estimaciones, y ninguna de las dos era prueba de que se hubiera descifrado una sesión VPN concreta.

Cite el trabajo por el mecanismo y por la degradación demostrada, no como una medición de su despliegue. Las estadísticas antiguas sobre cuántos servidores compartían un grupo predeterminado describen la internet de aquel año, no una red que usted pueda inspeccionar hoy. Lo útil que queda es la pregunta: si sus dispositivos siguen negociando un grupo que es pequeño o está débilmente validado.

Normalizado no es lo mismo que débil

RFC 7919 define grupos de campo finito con nombre para que ambos extremos acuerden un grupo por identificador y apliquen una política coherente. Estar normalizado es una ventaja, porque elimina la ambigüedad de la negociación y permite a una implementación rechazar tamaños no admitidos. Un grupo con nombre es débil solo cuando su tamaño queda por debajo de la política que usted dice seguir, no porque aparezca en un documento. La misma lógica se aplica a los grupos de curvas elípticas, que tienen una estructura distinta y modos de fallo distintos.

Mantenga las construcciones separadas cuando razone sobre ellas. Una conclusión sobre Diffie-Hellman de campo finito no dice nada sobre X25519, y una conclusión sobre un grupo MODP de 1024 bits no dice nada sobre uno de 3072 bits. La política de fuerza es por mecanismo, por tamaño y por versión de protocolo, y por eso la frase criptografía fuerte no es una afirmación revisable.

La autenticación es la otra mitad, y no sustituye. Un grupo fuerte sin verificación del par deja a un atacante en el medio, y un certificado válido no puede rescatar un intercambio de 768 bits. Revíselos como dos líneas independientes y luego confirme que ambos se negocian de verdad.

Lea el grupo negociado en una conexión real

Lea el grupo negociado desde el dispositivo y no desde la plantilla de configuración. Las plantillas describen la intención, y el valor interesante es el que ambos extremos acordaron durante el último handshake. En un extremo IPsec la salida de estado normalmente imprime la propuesta seleccionada, incluido el grupo MODP.

Capture esa línea antes y después de un cambio de política, y guarde las dos en el registro del cambio. La comparación es la prueba.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Si después del cambio el estado sigue mostrando el grupo antiguo, la conexión no ha renegociado y la edición de la configuración no ha demostrado nada. Reinicie el par o borre la asociación de seguridad, y vuelva a leer el estado. Una política aplicada solo a conexiones nuevas dejará los túneles de larga duración con los parámetros antiguos mientras estén levantados.

Compruebe el grupo y la identidad del par por separado

Separe qué protege el grupo de quién está al otro lado. Registre el método de intercambio de claves, el tamaño del grupo y el método de autenticación como tres campos, porque fallan de forma independiente. Un túnel que ha negociado un grupo de 3072 bits pero acepta cualquier certificado no es el mismo riesgo que uno que fija un par y usa un grupo de 2048 bits.

Escriba los criterios de aceptación antes de que empiece la revisión, para que el resultado sea una comparación y no una opinión. Un tamaño mínimo de grupo por versión de protocolo, una lista blanca de grupos con nombre y la verificación obligatoria del par bastan para hacer la decisión mecánica. La ambigüedad en esa lista es lo que convierte una revisión en una discusión, y las discusiones no se remedian. Entonces la salida es una lista de extremos que incumplen una regla declarada.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Cierre el ciclo releyendo los valores negociados después de la remediación. Un archivo de configuración conforme no es prueba de que un túnel lo haya recogido. La salida de estado y un handshake nuevo son la prueba, y recogerlos lleva menos tiempo que la reunión sobre si hacen falta.