Y a-t-il des avantages de sécurité à déployer des groupes DH SSH personnalisés sur des systèmes client uniquement?

16

Une stratégie d'atténuation suggérée contre les attaques liées à Logjam sur SSH consiste à générer des groupes Diffie-Hellman SSH personnalisés en utilisant quelque chose comme (le ci-dessous étant pour OpenSSH)

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

suivi du remplacement du fichier de modules à l'échelle du système par le fichier de sortie moduli-2048. ( ssh-keygen -Gest utilisé pour générer des candidats DH-GEX premiers et ssh-keygen -Tpour tester la sécurité des candidats générés.)

C'est assez clairement une chose raisonnable à faire sur des serveurs SSH qui autrement utiliseraient des groupes bien connus qui se prêtent bien au précalcul, mais y a-t-il des avantages en termes de sécurité à déployer des groupes DH SSH personnalisés sur des systèmes client uniquement? (Autrement dit, les systèmes qui se connectent aux serveurs SSH, mais qui n'agissent jamais eux-mêmes comme serveurs SSH.)

Je suis principalement intéressé par les réponses relatives à OpenSSH sur Linux, mais des réponses plus génériques seraient également appréciées.

ssh ssh-keys logjam

— un CVn
source

18

Vous pouvez le faire si vous le voulez vraiment, mais cela ne me dérangerait pas de régénérer les paramètres DH à 2048 bits pour OpenSSH. Il y a des choses beaucoup plus importantes que vous devez faire pour sécuriser SSH, comme désactiver la crypto faible .

Ce que je ferais , c'est supprimer ceux qui sont inférieurs à 2048 bits.

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

Au cas où vous ne l'auriez pas remarqué, OpenSSH est livré avec un grand nombre de modules pré-générés, jusqu'à 8192 bits. Bien que nous soyons certainement préoccupés par les nombres premiers de 1024 bits aujourd'hui, ceux de 2048 bits sont considérés comme sûrs dans un avenir prévisible. Et même si cela finira par changer, ce pourrait être la semaine prochaine, mais il est plus probable que ce soit longtemps après que nous soyons devenus retraités ...

Il y a aussi ce petit quelque chose de curieux dans la ssh-keygenpage de manuel:

Il est important que ce fichier contienne des modules d'une plage de longueurs de bits et que les deux extrémités d'une connexion partagent des modules communs.

Ce qui semble plaider contre le remplacement des modules existants, bien qu'il ne fournisse pas vraiment la raison réelle de le faire.

— Michael Hampton
source

Connexes: Diffie-Hellman utilisant un module différent des deux côtés sur la cryptographie . À ma connaissance limitée, il semble que s'il n'y a pas de modules partagés d'une longueur souhaitée, Diffie-Hellman avec un groupe de cette longueur n'est pas possible dans le cas général, et pourrait ne pas être possible dans aucun cas spécifique. Par conséquent, le partage de modules entre les deux points d'extrémité est une exigence mathématique du protocole d'échange de clés Diffie-Hellman, et la tentative d'effectuer un échange de clés Diffie-Hellman entre deux points d'extrémité qui n'ont pas de modules communs échouera.

— un CVn

2

La RFC 4419 [ tools.ietf.org/html/rfc4419] sert précisément à permettre au serveur de fournir des paramètres DH personnalisés. Le serveur envoie ses paramètres candidats au client, et si le client est d'accord, les deux parties utilisent les paramètres fournis par le serveur pour générer un secret partagé qui est utilisé comme clé de session. Donc, c'est très bien si le serveur et le client n'ont pas les mêmes entrées dans leur fichier de modules.

— Brian Minton

2

La réponse est: Non. Il n'y a aucun avantage. :)

/etc/ssh/moduli Le fichier est utilisé uniquement pour le côté serveur.

Vous n'avez pas à vous soucier de ce fichier pour le côté client SSH:

Vous pouvez suivre l'exécution du client SSH et vérifier qu'il n'ouvre pas ce fichier.

$ strace -e openat ssh user@localhost

— Adi Roiban
source