Grupo DH compartido, segredos novos: por que o ataque sae máis barato

Os parámetros do grupo son públicos por deseño, e esa publicidade é xusto o que os fai fáciles de pasar por alto. En Diffie-Hellman de corpo finito o módulo e o xerador son compartidos, mentres que os expoñentes privados e as claves de sesión resultantes non o son. A fase cara dun ataque con criba de corpo de números depende do grupo e non dun só intercambio, así que un único grupo feble usado en todas partes convértese nunha responsabilidade compartida. Chamar públicos aos parámetros é exacto e non vén ao caso, porque o custo que se reutiliza é o custo de atacar ese grupo.

A metade pública non é a metade vulnerable, e aí está a trampa

O habitual medio argumento di que os parámetros se publican nunha norma, así que un atacante xa os coñece e ocultalos non cambiaría nada. Ambas afirmacións son certas e ningunha se deduce da outra. Un grupo predeterminado enviado é público, e un grupo privado que vostede xerou a semana pasada tamén é visible para calquera que complete o apretón de mans. O segredo nunca foi o control; sérono a forza e a validación.

O que si cambia é cantos sitios comparten a mesma debilidade. Unha organización que xera o seu propio grupo de 2048 bits paga o seu propio custo de ataque, mentres que un valor predeterminado de protocolo escollido por millóns amortiza un só custo entre todos eles. É nese sentido no que un grupo pouco común non é automaticamente mellor. Un grupo pouco habitual que é demasiado pequeno non é máis que un segredo compartido máis pequeno con menos ollos enriba.

A validación importa tanto como o tamaño. Un par que envía un módulo con factores pequenos, ou un que non ten a forma que o protocolo espera, pode filtrar información sobre o expoñente privado mesmo cando a lonxitude en bits parece respectable. As bibliotecas que rexeitan parámetros mal formados na entrada fan traballo real, e por iso a análise de parámetros feita a man é un mal lugar onde aforrar esforzo.

Que compra realmente o precálculo a un atacante

A criba de corpo de números ten unha fase que depende só do número primo, e a súa saída é reutilizable contra cada intercambio que usa ese primo. Ese é todo o mecanismo detrás da preocupación histórica: a parte cara págase unha vez e o custo marxinal de cada sesión posterior baixa. Os expoñentes novos aínda protexen cada intercambio individual dun observador pasivo, sempre que o grupo sexa o bastante grande para facer a criba inviable. As dúas afirmacións son compatibles, e a maioría das discusións sobre este tema veñen de escoller unha e descartar a outra.

O traballo de Logjam de 2015 demostrou unha degradación a Diffie-Hellman de 512 bits de grao exportación e estimou o que custaría atacar grupos maiores e moi reutilizados con recursos significativos. A demostración era concreta, as estimacións eran estimacións, e ningunha das dúas era proba de que se descifrase unha sesión VPN concreta.

Cite o traballo polo mecanismo e pola degradación demostrada, non como unha medición do seu despregamento. As estatísticas antigas sobre cantos servidores compartían un grupo predeterminado describen a internet daquel ano, non unha rede que vostede poida inspeccionar hoxe. O útil que queda é a pregunta: se os seus dispositivos seguen negociando un grupo que é pequeno ou está feblemente validado.

Normalizado non é o mesmo que feble

RFC 7919 define grupos de corpo finito con nome para que ambos extremos acorden un grupo por identificador e apliquen unha política coherente. Estar normalizado é unha vantaxe, porque elimina a ambigüidade da negociación e permite a unha implementación rexeitar tamaños non admitidos. Un grupo con nome é feble só cando o seu tamaño queda por baixo da política que vostede di seguir, non porque apareza nun documento. A mesma lóxica se aplica aos grupos de curvas elípticas, que teñen unha estrutura distinta e modos de fallo distintos.

Manteña as construcións separadas cando razone sobre elas. Unha conclusión sobre Diffie-Hellman de corpo finito non di nada sobre X25519, e unha conclusión sobre un grupo MODP de 1024 bits non di nada sobre un de 3072 bits. A política de forza é por mecanismo, por tamaño e por versión de protocolo, e por iso a frase criptografía forte non é unha afirmación revisable.

A autenticación é a outra metade, e non substitúe. Un grupo forte sen verificación do par deixa un atacante no medio, e un certificado válido non pode rescatar un intercambio de 768 bits. Revíseos como dúas liñas independentes e logo confirme que ambos se negocian de verdade.

Lea o grupo negociado nunha conexión real

Lea o grupo negociado desde o dispositivo e non desde o modelo de configuración. Os modelos describen a intención, e o valor interesante é o que ambos extremos acordaron durante o último apretón de mans. Nun extremo IPsec a saída de estado normalmente imprime a proposta seleccionada, incluído o grupo MODP.

Capture esa liña antes e despois dun cambio de política, e garde as dúas no rexistro do cambio. A comparación é a proba.

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

Se despois do cambio o estado segue mostrando o grupo antigo, a conexión non renegociou e a edición da configuración non demostrou nada. Reinicie o par ou borre a asociación de seguridade, e volva ler o estado. Unha política aplicada só a conexións novas deixará os túneles de longa duración cos parámetros antigos mentres estean levantados.

Comprobe o grupo e a identidade do par por separado

Separe que protexe o grupo de quen está ao outro lado. Rexistre o método de intercambio de claves, o tamaño do grupo e o método de autenticación como tres campos, porque fallan de forma independente. Un túnel que negociou un grupo de 3072 bits pero acepta calquera certificado non é o mesmo risco que un que fixa un par e usa un grupo de 2048 bits.

Escriba os criterios de aceptación antes de que comece a revisión, para que o resultado sexa unha comparación e non unha opinión. Un tamaño mínimo de grupo por versión de protocolo, unha lista branca de grupos con nome e a verificación obrigatoria do par abondan para facer a decisión mecánica. A ambigüidade nesa lista é o que converte unha revisión nunha discusión, e as discusións non se remedian. Entón a saída é unha lista de extremos que incumpran unha regra declarada.

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

Pecha o ciclo relendo os valores negociados despois da remediación. Un ficheiro de configuración conforme non é proba de que un túnel o collese. A saída de estado e un apretón de mans novo son a proba, e recollelos leva menos tempo que a reunión sobre se fan falta.