Gruppo DH condiviso, segreti nuovi: perché l’attacco costa meno

I parametri del gruppo sono pubblici per progetto, e proprio questa pubblicità li rende facili da ignorare. In Diffie-Hellman su campo finito il modulo e il generatore sono condivisi, mentre gli esponenti privati e le chiavi di sessione risultanti non lo sono. La fase costosa di un attacco con crivello di campo numerico dipende dal gruppo e non da un singolo scambio, quindi un unico gruppo debole usato ovunque diventa una responsabilità condivisa. Chiamare pubblici i parametri è esatto e fuori tema, perché il costo riutilizzato è il costo di attaccare proprio quel gruppo.

La metà pubblica non è la metà vulnerabile, ed è qui la trappola

Il solito mezzo argomento dice che i parametri sono pubblicati in una norma, quindi un attaccante li conosce già e nasconderli non cambierebbe nulla. Entrambe le affermazioni sono vere e nessuna deriva dall’altra. Un gruppo predefinito spedito è pubblico, e un gruppo privato che avete generato la settimana scorsa è visibile a chiunque completi la stretta di mano. La segretezza non è mai stata il controllo; lo sono la forza e la validazione.

Ciò che cambia è quanti posti condividono la stessa debolezza. Un’organizzazione che genera il proprio gruppo a 2048 bit paga il proprio costo d’attacco, mentre un valore predefinito di protocollo scelto da milioni ammortizza un solo costo su tutti loro. È in questo senso che un gruppo poco comune non è automaticamente migliore. Un gruppo inusuale troppo piccolo non è altro che un segreto condiviso più piccolo con meno occhi addosso.

La validazione conta quanto la dimensione. Un pari che invia un modulo con fattori piccoli, o uno che non ha la forma che il protocollo si aspetta, può far trapelare informazioni sull’esponente privato anche quando la lunghezza in bit sembra rispettabile. Le librerie che rifiutano parametri malformati all’ingresso fanno un lavoro reale, ed è per questo che l’analisi dei parametri scritta a mano è un cattivo posto dove risparmiare fatica.

Che cosa compra davvero il precalcolo a un attaccante

Il crivello di campo numerico ha una fase che dipende solo dal numero primo, e il suo risultato è riutilizzabile contro ogni scambio che usa quel primo. È tutto il meccanismo dietro la preoccupazione storica: la parte costosa si paga una volta e il costo marginale di ogni sessione successiva cala. Gli esponenti nuovi proteggono ancora ogni singolo scambio da un osservatore passivo, purché il gruppo sia abbastanza grande da rendere il crivello irrealizzabile. Le due affermazioni sono compatibili, e la maggior parte delle discussioni sull’argomento nasce dal sceglierne una e scartare l’altra.

Il lavoro Logjam del 2015 ha dimostrato un downgrade a Diffie-Hellman a 512 bit di qualità export e ha stimato quanto costerebbe attaccare gruppi più grandi e molto riutilizzati con risorse significative. La dimostrazione era concreta, le stime erano stime, e nessuna delle due era la prova che una particolare sessione VPN fosse stata decifrata.

Citate il lavoro per il meccanismo e per il downgrade dimostrato, non come misura del vostro dispiegamento. Le vecchie statistiche su quanti server condividevano un gruppo predefinito descrivono l’internet di quell’anno, non una rete che potete ispezionare oggi. Ciò che vale la pena portare via è la domanda: i vostri dispositivi negoziano ancora un gruppo piccolo o debolmente validato?

Standardizzato non è sinonimo di debole

La RFC 7919 definisce gruppi di campo finito con nome affinché entrambe le estremità concordino un gruppo per identificatore e applichino una politica coerente. Essere standardizzato è un vantaggio, perché elimina l’ambiguità della negoziazione e consente a un’implementazione di rifiutare dimensioni non supportate. Un gruppo con nome è debole solo quando la sua dimensione scende sotto la politica che dichiarate di seguire, non perché compare in un documento. La stessa logica vale per i gruppi di curve ellittiche, che hanno una struttura diversa e modi di guasto diversi.

Tenete separate le costruzioni quando ragionate su di esse. Una conclusione su Diffie-Hellman su campo finito non dice nulla su X25519, e una conclusione su un gruppo MODP a 1024 bit non dice nulla su uno a 3072 bit. La politica di forza è per meccanismo, per dimensione e per versione di protocollo, ed è per questo che la frase crittografia forte non è un’affermazione verificabile.

L’autenticazione è l’altra metà, e non sostituisce. Un gruppo forte senza verifica del pari lascia un attaccante nel mezzo, e un certificato valido non può salvare uno scambio a 768 bit. Esaminateli come due linee indipendenti, poi confermate che entrambe sono davvero negoziate.

Leggete il gruppo negoziato su una connessione reale

Leggete il gruppo negoziato dal dispositivo e non dal modello di configurazione. I modelli descrivono l’intenzione, e il valore interessante è quello su cui entrambe le estremità si sono accordate durante l’ultima stretta di mano. Su un endpoint IPsec l’output di stato di solito stampa la proposta selezionata, incluso il gruppo MODP.

Catturate quella riga prima e dopo un cambio di politica, e conservate entrambe nel registro delle modifiche. Il confronto è la prova.

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

Se dopo il cambio lo stato mostra ancora il gruppo vecchio, la connessione non ha rinegoziato e la modifica di configurazione non ha dimostrato nulla. Riavviate il pari o cancellate l’associazione di sicurezza, poi rileggete lo stato. Una politica applicata solo alle nuove connessioni lascerà i tunnel di lunga durata sui parametri vecchi finché restano attivi.

Verificate il gruppo e l’identità del pari separatamente

Separate ciò che il gruppo protegge da chi si trova all’altro capo. Registrate il metodo di scambio delle chiavi, la dimensione del gruppo e il metodo di autenticazione come tre campi, perché falliscono in modo indipendente. Un tunnel che ha negoziato un gruppo a 3072 bit ma accetta qualsiasi certificato non è lo stesso rischio di uno che blocca un pari e usa un gruppo a 2048 bit.

Scrivete i criteri di accettazione prima che inizi la revisione, così che il risultato sia un confronto e non un’opinione. Una dimensione minima di gruppo per versione di protocollo, una lista di autorizzazione dei gruppi con nome e la verifica obbligatoria del pari bastano a rendere la decisione meccanica. L’ambiguità in quella lista è ciò che trasforma una revisione in una discussione, e le discussioni non vengono corrette. Allora l’output è una lista di endpoint che violano una regola dichiarata.

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

Chiudete il cerchio rileggendo i valori negoziati dopo la correzione. Un file di configurazione conforme non è prova che un tunnel lo abbia recepito. L’output di stato e una stretta di mano nuova sono la prova, e raccoglierli richiede meno tempo della riunione sul se servano.