Un handshake VPN échoué est-il vraiment une attaque par rétrogradation ?

Un handshake qui se termine par une erreur ressemble à une attaque jusqu’à ce qu’on lise le message, et la plupart du temps c’est de l’arithmétique : aucune proposition commune, un certificat expiré ou un paquet qui n’est jamais arrivé. Une attaque par rétrogradation est une chose précise : un adversaire qui pousse les deux extrémités vers un comportement plus faible qu’elles ne l’auraient choisi, et elle laisse des preuves différentes. Traiter chaque échec comme une malveillance vous envoie chercher une victime qui n’existe peut-être pas, tandis que traiter une vraie rétrogradation comme un bug de configuration laisse le résultat plus faible en place. Les deux erreurs coûtent différemment, et une seule est bon marché à corriger.

Ce qu’une attaque par rétrogradation change réellement

Le but n’est pas de casser le chiffrement ni de deviner une clé. C’est d’influencer la négociation pour que les deux côtés s’arrêtent sur une version plus ancienne ou un algorithme plus faible que l’attaquant peut gérer, ou de faire croire à un côté que l’autre ne prend en charge que cela.

Ce qui change, c’est l’accord, pas l’authentification. Si l’attaquant peut modifier l’offre sans être détecté, les pairs peuvent toujours terminer un handshake et toujours s’authentifier mutuellement, avec des paramètres que l’attaquant préfère. C’est pourquoi la question intéressante est de savoir si la négociation elle-même est couverte par la protection d’intégrité.

Pourquoi la négociation elle-même doit être authentifiée

TLS 1.3 rend cette protection explicite. Un client qui a proposé la version la plus récente peut détecter un serveur qui est retombé en silence, parce que la valeur aléatoire du serveur porte un motif fixe lorsqu’il négocie 1.2 ou moins, et le client doit abandonner en la voyant. La transcription complète est aussi couverte par les messages finaux, si bien qu’une modification n’importe où dans la négociation échoue plus tard au lieu de passer discrètement.

Les anciennes versions du protocole avaient des histoires plus faibles, et c’est exactement pourquoi les règles de repli comptent. Un point de terminaison TLS 1.0 dans la même configuration n’est pas une attaque par rétrogradation ; c’est un résultat autorisé que vous avez choisi de permettre. La distinction est de savoir si le résultat plus faible vient d’une décision protégée ou d’un chemin non protégé qu’un intermédiaire pouvait influencer. Une fois formulé ainsi, la plupart des incidents se ramènent à une question de configuration.

IKEv2 se comporte différemment mais repose sur la même idée. La proposition est transportée dans un échange qui authentifie ensuite les deux pairs, donc un boîtier intermédiaire qui réécrit les algorithmes casse l’authentification au lieu de la piloter. Le canal de contrôle d’OpenVPN protège sa négociation avec TLS puis utilise ce canal pour convenir des chiffrements du canal de données, et c’est pourquoi la ligne de journal du canal de contrôle est la plus intéressante.

La compatibilité configurée n’est pas une attaque

Un administrateur peut délibérément autoriser des choix plus anciens pour prendre en charge un client documenté, et cette décision est visible dans la configuration. Un attaquant ne peut pas créer cette configuration ; il peut seulement exploiter un chemin qui lui permet d’influencer l’offre.

La réparation dangereuse est celle qui supprime la preuve de la différence. Activer toutes les options héritées, désactiver la vérification des certificats ou accepter n’importe quel chiffrement pour faire disparaître une erreur élargit ce que le point de terminaison acceptera, et supprime les contrôles qui auraient signalé le résultat plus faible.

Si vous devez garder une ancienne option, nommez la raison et le client dans le commentaire de configuration, puis limitez l’option au profil qui en a besoin. Une exception de compatibilité limitée à un seul listener est auditable ; appliquée globalement, ce n’est qu’un défaut plus faible dont personne ne se souvient de l’avoir choisi.

Lisez l’échec avant de nommer une cause

Conservez la chaîne d’erreur exacte, les versions du client et du serveur et l’heure avant tout changement. Puis classez : les pairs étaient-ils en désaccord sur une proposition, le chemin des paquets a-t-il échoué, ou un côté a-t-il rejeté un paramètre qu’il acceptait autrefois ?

Un désaccord de proposition nomme généralement les versions ou les algorithmes fautifs et échoue au même point à chaque fois. Un problème de routage ou de MTU se bloque ou expire, et il varie souvent selon le réseau. Un certificat expiré produit une erreur de vérification et non de négociation.

Rien de tout cela n’est la preuve d’un attaquant. Attribuer une cause malveillante au premier échec est l’erreur, car cela masque le bug déterministe qui échouera de nouveau demain.

Confirmez ce qui a réellement été choisi

Après toute correction, lisez le résultat négocié au lieu de supposer que la connexion s’est établie. Une connexion qui réussit parce que la vérification a été supprimée est le résultat que vous cherchiez à éviter. Les deux commandes suivantes montrent la version et le chiffrement choisis pour un point de terminaison devant TLS, plus la ligne du canal de contrôle du journal d’un serveur OpenVPN.

openssl s_client -connect 198.51.100.30:443 -servername vpn.example.net -brief </dev/null
grep -iE 'Control Channel|Data Channel' /var/log/openvpn.log | tail -5

Comparez le résultat à la configuration que vous vouliez, pas à ce qui se connecte maintenant. Si la version choisie est plus ancienne que le minimum autorisé, c’est le profil ou la liste de repli qu’il faut regarder, et la réponse est de corriger cette liste plutôt que de déclarer une attaque et de tout reconstruire autour.