DES contre 3DES dans un VPN : pourquoi les deux sont la mauvaise mise à niveau

Les deux chiffrements sont obsolètes, et aucun n'est la bonne cible pour le trafic nouveau. La comparaison utile n'est pas DES contre 3DES ; c'est un algorithme retiré contre un algorithme maintenu. Si une passerelle propose encore l'un ou l'autre, le travail consiste à trouver ce qui l'exige et à supprimer cette exigence, non à choisir le plus fort de deux impasses.

La comparaison que l'on cherche encore est la mauvaise

Les réponses écrites dans les années 2000 comparent DES au triple DES et concluent que le triple DES est plus fort. C'était raisonnable alors et c'est inutile aujourd'hui, car les deux sont retirés pour protéger le trafic nouveau et le choix entre eux est un choix entre deux impasses.

Le NIST a retiré la norme DES en 2005, et sa recommandation TDEA a été retirée en janvier 2024, après l'expiration fin 2023 du délai d'application de TDEA à une nouvelle protection cryptographique. Ces dates décrivent une transition, pas un classement. Une session courte ou un message de faible valeur ne rouvrent pas la question, car le statut de l'algorithme ne dépend pas de la durée d'utilisation de la clé.

Le renouvellement de la clé est un contrôle distinct, et il ne rétablit pas l'approbation.

Séparez la négociation du chemin de données

Les protocoles VPN négocient la protection à plus d'un endroit. Un canal de contrôle peut utiliser une suite tandis que les données transportées en utilisent une autre, et une liste de propositions dit seulement ce qu'un pair est prêt à accepter. Lisez le résultat négocié, pas l'offre. Cette distinction explique une confusion courante : une passerelle liste encore un algorithme ancien et l'opérateur suppose qu'il est utilisé, alors qu'il peut être proposé et jamais sélectionné, ou sélectionné pour un seul pair ancien.

Sur une passerelle IPsec, la sortie pertinente est l'association de sécurité ; sur OpenVPN ce sont le chiffrement et les paramètres TLS du journal de connexion. Les deux disent ce qui a été sélectionné. Aucun n'est prouvé par une option ancienne encore présente dans un fichier de configuration.

Si vous ne voyez pas le résultat négocié, vous ne pouvez pas affirmer que le chiffrement a été retiré.

Trouvez le composant qui le demande encore

Les exigences héritées viennent de trois endroits : un client ancien qui n'offre rien de mieux, une politique de passerelle qui liste encore l'algorithme, et un appareil qui ne parle que l'ancien protocole. Chacun a une solution différente. Demandez au propriétaire de la contrainte lequel c'est avant d'activer un fournisseur de compatibilité, car l'activer affecte chaque pair qui se connecte.

Pour un seul appareil qui ne peut pas encore être remplacé, placez une passerelle maintenue devant lui et limitez ce que cette frontière transporte. Cela contient l'ancien chiffrement sans que chaque utilisateur distant en hérite.

Le confinement n'est pas un correctif, et il ne rend pas l'hôte ancien fiable.

Migrez avec les contrôles que vous avez déjà

Une migration est terminée lorsque les pairs prévus se connectent avec le profil maintenu, que la suite négociée est celle attendue et que l'application fonctionne. Maintenez la vérification de l'identité du serveur et les contrôles de compte tout du long ; un changement de chiffrement n'est pas une raison de les relâcher.

openvpn --version
openssl ciphers -v 'DEFAULT:!DES:!3DES'

Consignez les versions du client et de la passerelle à côté du résultat négocié, afin que la prochaine revue puisse dire ce qui a réellement changé.

Retirez l'autorisation ancienne par son propriétaire, puis confirmez qu'un pair qui n'offre que l'algorithme retiré est désormais refusé. Une migration qui laisse l'ancienne option activée est une migration qui n'a pas eu lieu. Conservez la preuve du refus avec l'enregistrement du changement, car le prochain audit demandera comment vous le savez, et une ligne de configuration supprimée est une preuve plus faible qu'un refus journalisé. Ajoutez la date du test et l'identité du pair à cet enregistrement tant que la session est encore fraîche.

Les données historiques sont un autre problème

Lire une archive protégée il y a des années peut légitimement exiger l'ancien algorithme. C'est le déchiffrement d'un matériel existant, et ce n'est pas la même tâche que protéger le trafic nouveau.

Gardez ce travail sur un hôte isolé avec un objectif documenté et une courte liste de qui peut l'exécuter.

La distinction compte parce que c'est la seule raison honnête de garder un chiffrement retiré disponible. Elle justifie un outil à portée limitée, jamais une ligne permanente dans un profil VPN public.