Ci sono dei vantaggi in termini di sicurezza nella distribuzione di gruppi DH SSH personalizzati su sistemi solo client?

16

Una strategia di mitigazione suggerita contro gli attacchi relativi a Logjam su SSH è quella di generare gruppi SSH Diffie-Hellman personalizzati usando qualcosa del genere (il seguito è per OpenSSH)

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

seguito dalla sostituzione del file dei moduli a livello di sistema con il file di output moduli-2048. ( ssh-keygen -Gviene utilizzato per generare numeri primi DH-GEX candidati e ssh-keygen -Tper testare la sicurezza dei candidati generati).

Questa è chiaramente una cosa ragionevole da fare sui server SSH che altrimenti utilizzerebbero gruppi ben noti che si prestano bene al pre-calcolo, ma ci sono dei vantaggi di sicurezza nel distribuire gruppi DH SSH personalizzati su sistemi solo client? (Cioè, i sistemi che si collegano ai server SSH, ma non agiscono mai da soli come server SSH.)

Sono principalmente interessato alle risposte relative a OpenSSH su Linux, ma sarebbero apprezzate anche risposte più generiche.

ssh ssh-keys logjam

— un CVn
fonte

18

Puoi farlo se vuoi davvero, ma non mi preoccuperei di rigenerare i parametri DH a 2048 bit per OpenSSH. Ci sono cose molto più importanti che devi fare per proteggere SSH, come disabilitare la crittografia debole .

Quello che vorrei fare è eliminare quelli esistenti che sono meno di 2048 bit.

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

Nel caso non l'avessi notato, OpenSSH viene fornito con un gran numero di moduli pre-generati, fino a 8192 bit. Mentre oggi siamo sicuramente preoccupati per i numeri primi a 1024 bit, si ritiene che quelli a 2048 bit siano sicuri per il prossimo futuro. E mentre alla fine cambierà, potrebbe essere la prossima settimana, ma è più probabile che passi molto tempo dopo che siamo diventati pensionati ...

C'è anche questo curioso bit nella ssh-keygenpagina man:

È importante che questo file contenga moduli di un intervallo di lunghezze di bit e che entrambe le estremità di una connessione condividano moduli comuni.

Il che sembra discutere contro la sostituzione di moduli esistenti, anche se in realtà non fornisce la vera ragione per farlo.

— Michael Hampton
fonte

Correlati: Diffie-Hellman utilizza un modulo diverso su entrambi i lati della crittografia . Per mia comprensione limitata, sembra che se non ci sono moduli condivisi di una lunghezza desiderata, Diffie-Hellman con un gruppo di quella lunghezza non è possibile nel caso generale e potrebbe non essere possibile in nessun caso specifico. Quindi, avere moduli condivisi tra i due endpoint è un requisito matematico del protocollo di scambio di chiavi Diffie-Hellman e tentare di eseguire uno scambio di chiavi di Diffie-Hellman tra due endpoint che non hanno moduli comuni fallirà.

— un CVn del

2

RFC 4419 [ tools.ietf.org/html/rfc4419] è proprio per consentire al server di fornire parametri DH personalizzati. Il server invia i parametri candidati al client e, se il client è d'accordo, entrambe le parti utilizzano i parametri forniti dal server per generare un segreto condiviso che viene utilizzato come chiave di sessione. Quindi, va benissimo se il server e il client non hanno le stesse voci nel loro file moduli.

— Brian Minton,

2

La risposta è: No. Non ci sono benefici. :)

/etc/ssh/moduli il file viene utilizzato solo per il lato server.

Non devi preoccuparti di quel file per il lato client SSH:

È possibile tracciare l'esecuzione del client SSH e verificare che non apra quel file.

$ strace -e openat ssh user@localhost

— Adi Roiban
fonte