Les clés de 8192 bits bloquent la poignée de main ; le DH de 1024 bits est refusé

Un serveur a des clients qui se bloquent un moment puis se reconnectent, et un autre refuse les connexions immédiatement avec un message sur la taille de la clé. Ils ressemblent à des bogues différents et c’est le même bogue pointé dans des directions opposées. La cryptographie de la poignée de main a un coût qui augmente avec la taille des paramètres, et elle a aussi un plancher sous lequel les bibliothèques modernes ne descendent pas. Dimensionner le matériel est la liste de contrôle, et le premier point est de décider lequel des deux défauts vous avez réellement.

Lisez l’échec avant de régénérer quoi que ce soit

Le minutage vous en dit l’essentiel. Une poignée de main qui consomme plusieurs secondes puis meurt signifie généralement que le calcul a dépassé la patience du pair, ce qui pointe vers des paramètres trop grands pour le matériel ou pour le délai d’attente. Un refus immédiat qui nomme une taille de clé ou de groupe pointe dans l’autre sens, vers du matériel que la bibliothèque n’acceptera pas du tout.

Ces deux cas demandent des corrections opposées, et c’est là que la plupart des tentatives échouent. Régénérer des paramètres de 8192 bits sur un client qui a déjà refusé un petit groupe aggrave le cas lent sans rien faire pour le rapide. Notez quel symptôme vous avez observé avant de toucher à un fichier.

Vérifiez ensuite ce qu’on demande au pair. Un serveur configuré pour un grand groupe de corps fini force chaque client à dépenser le même temps CPU à chaque renégociation, pas seulement à la connexion. Si le problème apparaît à intervalle régulier plutôt qu’au démarrage, cet intervalle est un indice fort sur le réglage coûteux. La renégociation répète tout le calcul, donc un blocage qui revient toutes les heures est généralement le même coût payé de nouveau.

Le cas lent : des paramètres que la machine ne peut pas se permettre

Le travail de Diffie-Hellman et de RSA croît vite avec la taille de la clé, et tout cela se passe avant qu’aucun trafic ne circule dans le tunnel. Sur un petit routeur ou un client peu puissant, un groupe suffisamment grand peut pousser l’échange au-delà du délai d’attente de l’autre côté, si bien que la connexion réessaie ou semble simplement bloquée sans aucune erreur.

La correction consiste à descendre à une taille que chaque pair prend en charge et que chaque appareil peut calculer confortablement. Une clé RSA de 2048 bits et un groupe de 2048 bits restent une base largement compatible ; aller plus grand n’aide que si tous les pairs sont d’accord et que le CPU peut le payer à chaque renégociation. Tout ce qui dépasse cette base est un compromis délibéré, pas une amélioration.

La taille n’est pas un score, et le plus grand nombre d’un tableau comparatif n’est pas automatiquement le bon choix. Choisissez la plus petite valeur que votre politique autorise et que tous les pairs acceptent, puis mesurez la poignée de main au lieu de supposer qu’elle s’est améliorée. Un groupe plus petit qui expire encore vous dit que la taille n’a jamais été toute l’histoire.

Le cas rapide : un groupe que la bibliothèque refuse

Les compilations modernes d’OpenSSL rejettent carrément les plus petits groupes de corps fini, et un niveau de sécurité relevé pousse encore le plancher plus haut. Le micrologiciel de routeur qui embarque un fichier de paramètres vieux de décennies est la source habituelle, et le symptôme est une connexion qui échoue aussitôt avec un message nommant le groupe ou la taille de clé. Rien dans cet échec n’est intermittent, et c’est ce qui le rend facile à reconnaître.

Remplacez le fichier au lieu de modifier la configuration pour contourner la vérification. Générez un groupe actuel, validez-le, puis installez-le là où le démon le lit réellement. Gardez l’ancien fichier jusqu’à ce qu’un client se soit connecté avec succès avec le nouveau :

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

La commande de vérification valide le fichier et n’affiche rien d’utile lorsqu’elle passe ; le listage confirme que vous avez remplacé le fichier que le service charge, et non une copie périmée à côté. Pointez la configuration vers ce chemin, redémarrez le démon et confirmez qu’un client qui échouait auparavant termine désormais la poignée de main.

Si le serveur définit aussi un niveau de sécurité ou un profil de certificat, lisez-les avant de conclure que le groupe était fautif. Un profil qui exige une classe plus stricte peut rejeter du matériel que la valeur par défaut aurait accepté, et retirer ce réglage est un changement plus étroit que de désactiver la vérification globalement.

Choisissez une taille pour le pair et le matériel

Déterminez ce que l’extrémité distante peut supporter avant de générer quoi que ce soit d’exotique. Un appareil trop ancien pour un groupe de 2048 bits est un appareil à remplacer, car pointer le serveur vers un groupe plus faible ne fait que transformer une plainte de compatibilité en panne. Les corrections durables vont vers des logiciels plus récents, pas vers des paramètres plus anciens. Chaque exception temporaire dans ce domaine finit par devenir la configuration permanente.

Là où le CPU du serveur est la limite, changez d’algorithme au lieu de descendre sous la politique. Un échange de clés à courbe elliptique comme X25519 est nettement moins cher qu’un grand groupe de corps fini et largement pris en charge, ce qui en fait une meilleure réponse à une plainte de performance qu’un module RSA plus petit.

Quoi que vous choisissiez, testez avec une vraie connexion et regardez combien de temps prend la poignée de main, pas seulement si elle finit par se connecter. Une connexion qui réussit en douze secondes a la même cause racine qu’une qui échoue à quinze.

Notez le choix pour qu’une reconstruction ne le défasse pas

Gardez le fichier de paramètres sous gestion de configuration et écrivez à côté la taille, la raison et la date. Un serveur reconstruit qui génère silencieusement ses propres valeurs par défaut est la façon dont le même défaut revient six mois plus tard sans que personne puisse expliquer la décision d’origine.

Notez les mêmes informations à côté du point de terminaison et du profil, pour qu’une revue n’ait pas à les reconstituer à partir d’une taille de fichier. Quand la prochaine connexion se bloque, cette note fait la différence entre une vérification de cinq minutes et une nouvelle enquête. Elle empêche aussi l’ingénieur suivant de résoudre le cas lent avec une correction destinée au rapide.