strongSwan 6.1 coupe IKEv1 par défaut et corrige 11 failles : si votre VPN IPsec casse, ce n’est peut-être pas un hasard

Il existe des logiciels que l’on installe, configure puis oublie pendant des années parce qu’ils font précisément ce qu’on leur demande sans venir réclamer une mise à jour graphique tous les quinze jours. strongSwan fait clairement partie de cette catégorie.

Cette implémentation open source d’IPsec est utilisée sous Linux, FreeBSD, macOS, Android et dans quantité d’équipements ou de distributions réseau pour créer des VPN site-à-site, connecter des utilisateurs distants ou sécuriser des communications entre infrastructures. La version 6.1.0, publiée le 7 septembre 2026, mérite toutefois qu’on aille jeter un œil à ses tunnels plutôt que de laisser apt upgrade régler la question en silence. Elle corrige en effet onze vulnérabilités de sécurité et marque une étape importante : IKEv1 n’est désormais plus activé par défaut.

Et ce dernier détail risque d’être beaucoup plus visible pour certains administrateurs que les onze CVE réunies.

strongSwan, le moteur IPsec que vous utilisez parfois sans le savoir

Pour simplifier, IPsec permet de créer des tunnels chiffrés au niveau réseau. C’est l’une des technologies historiques des VPN professionnels, notamment lorsqu’il faut connecter deux sites, établir un tunnel entre des pare-feu ou permettre à des utilisateurs de rejoindre un réseau distant.

strongSwan implémente notamment IKE, pour Internet Key Exchange, le protocole chargé de négocier les paramètres de sécurité et les clés nécessaires à la création du tunnel IPsec. Le projet prend en charge IKEv2 et, jusqu’à présent, continuait également à proposer IKEv1 pour assurer la compatibilité avec les infrastructures plus anciennes.

Le problème est qu’IKEv1 date d’une époque où Windows XP était encore une nouveauté, où les téléphones servaient principalement à téléphoner et où personne n’imaginait qu’un jour un frigo réclamerait une adresse IP.

Depuis, IKEv2 est devenu la solution moderne à privilégier, et les développeurs de strongSwan ont décidé que la compatibilité historique avait suffisamment duré.

IKEv1 passe officiellement sur la voie de garage

Avec strongSwan 6.1.0, IKEv1 est désactivé par défaut lors de la compilation. Il reste encore présent dans le code, mais il faut désormais le demander explicitement avec l’option --enable-ikev1. Les développeurs annoncent également que sa prise en charge devrait être totalement supprimée dans une future version, probablement dans l’année à venir, même si aucun calendrier définitif n’est encore fixé.

Le changement touche aussi la configuration : le paramètre version utilise maintenant IKEv2 par défaut. Une configuration demandant explicitement IKEv1, ou laissant volontairement le choix entre les deux versions, provoque désormais un avertissement.

D’un point de vue sécurité, difficile de reprocher au projet de vouloir enterrer un protocole aussi ancien. D’un point de vue administration système, cela signifie toutefois qu’un VPN parfaitement fonctionnel le lundi peut commencer à bouder après une mise à jour si l’équipement situé à l’autre bout du tunnel ne sait parler qu’IKEv1.

Et ce n’est pas uniquement théorique.

Debian a déjà eu droit au « pourquoi mon VPN ne marche plus ? »

Quelques jours seulement après l’arrivée de strongSwan 6.1.0 dans Debian, un utilisateur a ouvert un rapport de bug après avoir constaté qu’il ne pouvait plus se connecter à un serveur VPN SoftEther.

Dans ses logs, le message était assez explicite : IKE version 1 not supported.

Le passage de strongSwan 6.0.7 à 6.1.0 avait simplement supprimé la prise en charge d’IKEv1 dans le paquet concerné. L’utilisateur demandait donc à Debian de continuer à compiler strongSwan avec le support de l’ancien protocole pour maintenir la compatibilité avec son infrastructure.

Le même problème concerne potentiellement les firewalls, concentrateurs VPN, appliances industrielles ou équipements plus anciens qui ne proposent toujours pas IKEv2. Des projets utilisant strongSwan en interne ont d’ailleurs commencé à examiner la manière de conserver temporairement IKEv1 afin d’éviter une coupure brutale pour leurs utilisateurs.

Autrement dit, si vous administrez un VPN IPsec un peu ancien, la bonne stratégie consiste probablement à vérifier ce qu’il utilise avant que la mise à jour ne le fasse pour vous.

Onze vulnérabilités corrigées d’un coup

Si strongSwan 6.1.0 pousse vers IKEv2, ce n’est toutefois pas uniquement pour faire du ménage. La version corrige onze vulnérabilités, dont plusieurs touchent directement le traitement de messages reçus depuis le réseau.

Certaines peuvent provoquer un crash ou une consommation excessive de mémoire, entraînant un déni de service. D’autres concernent la gestion des certificats X.509 et PKCS#7. Une faille dans les plugins EAP-PEAP et EAP-TTLS peut entraîner une mauvaise association d’identité et potentiellement permettre un contournement d’autorisation.

Mais deux vulnérabilités attirent particulièrement l’attention.

La première, CVE-2026-78133, touche la gestion des collisions lors du renouvellement d’une association IKEv2. Elle peut provoquer un use-after-free et les développeurs indiquent qu’elle peut potentiellement conduire à une exécution de code à distance. Elle concerne les versions strongSwan 6.0.x antérieures à 6.1.0.

La seconde, CVE-2026-78135, concerne le traitement de certaines requêtes CREATE_CHILD_SA. Dans certaines conditions, un Child SA utilisable peut être créé avant la fin de l’authentification, ce qui n’est évidemment pas exactement le comportement que l’on attend d’un logiciel dont le métier consiste à empêcher les gens non authentifiés d’entrer.

Même les logs pouvaient finir par mettre le serveur à genoux

Parmi les correctifs figure également CVE-2026-78127 , une vulnérabilité assez représentative de ces petits bugs apparemment anodins qui deviennent beaucoup moins amusants sur un service exposé à Internet.

Lorsqu’il recevait certains messages IKE spécialement construits, strongSwan pouvait oublier de libérer correctement de petites structures utilisées pendant la génération des logs. Chaque message ne faisait perdre qu’une quantité réduite de mémoire, mais un attaquant pouvait répéter l’opération de nombreuses fois.

Résultat : la consommation mémoire augmentait progressivement jusqu’à pouvoir provoquer un déni de service, en particulier sur les appareils disposant de peu de RAM. Les protections anti-DoS déjà présentes dans strongSwan ralentissaient l’attaque sans parvenir à l’empêcher complètement.

C’est le genre de bug qui rappelle qu’en sécurité informatique, « seulement 80 octets » peut devenir une phrase dangereuse lorsqu’on ajoute « à chaque paquet reçu depuis Internet ».

Plusieurs failles étaient particulièrement liées à IKEv1

Un autre élément intéressant est que certaines vulnérabilités corrigées dans cette version disposent d’un chemin d’attaque distant principalement via IKEv1.

C’est notamment le cas de problèmes liés au traitement de conteneurs PKCS#7. L’un pouvait provoquer une fuite de mémoire lors du traitement de certificats et être déclenché avant authentification lorsqu’IKEv1 était accepté. Les développeurs précisent d’ailleurs explicitement que les serveurs refusant les connexions IKEv1 ne sont pas vulnérables par ce chemin d’attaque.

Une autre vulnérabilité dans le traitement de conteneurs PKCS#7 chiffrés pouvait conduire à un crash en manipulant certaines tailles de données. Là encore, l’exploitation distante concernait principalement les installations acceptant IKEv1 et chargeant les plugins impliqués.

Le choix de désactiver IKEv1 par défaut tombe donc à un moment particulièrement logique.

Et une partie de ces failles a été trouvée avec l’aide de l’IA

Petit détail assez savoureux : le projet strongSwan indique que plusieurs vulnérabilités de cette série ont été découvertes grâce à des améliorations dans l’analyse de sécurité assistée par intelligence artificielle.

Nous avons beaucoup parlé ces derniers mois des IA utilisées pour produire du malware, rechercher automatiquement des vulnérabilités ou aider à générer des exploits. Il est plutôt agréable de voir le même type de technologie participer également au nettoyage de briques réseau open source utilisées depuis des années.

Cela ne signifie évidemment pas qu’un chatbot a cliqué sur un bouton « trouvez-moi onze CVE » avant d’aller prendre son café. L’analyse automatisée et assistée par modèle reste intégrée à un travail de recherche, de validation et de correction effectué par des humains.

Mais sur un projet aussi ancien et complexe que strongSwan, la capacité à identifier des chemins de code inhabituels ou des comportements difficiles à provoquer manuellement devient clairement intéressante.

Pour une fois que l’IA trouve des failles avant de nous proposer d’ajouter de la colle sur une pizza, on ne va pas se plaindre.

strongSwan en profite également pour faire un gros ménage

La version 6.1.0 ne se limite pas aux correctifs de sécurité. Plusieurs plugins et composants anciens disparaissent également du projet, dont af-alg, blowfish, gcrypt, keychain, manager, soup ou encore différents composants TNC. Les développeurs recommandent même de ne plus activer ces éléments lors de la compilation des anciennes versions.

strongSwan ajoute aussi la prise en charge de la migration des Security Associations sous Linux, une nouveauté intéressante pour certaines configurations réseau avancées. Le projet continue donc son travail de modernisation tout en supprimant progressivement des composants historiques devenus difficiles à justifier.

C’est un cycle assez classique dans les gros projets open source : conserver éternellement toutes les anciennes fonctionnalités rend le logiciel plus compatible, mais augmente également la quantité de code à tester, maintenir et sécuriser.

À un moment, il faut choisir entre faire tourner le VPN de 2003 et réduire la surface d’attaque en 2026.

Comment savoir si vous êtes concerné ?

Si vous utilisez strongSwan directement, la première chose à faire est simplement de vérifier votre version. Le projet recommande les commandes swanctl --version ou ipsec version. La version actuelle est 6.1.0.

Si votre installation vient des dépôts de votre distribution Linux, mieux vaut privilégier les paquets fournis par celle-ci plutôt que compiler une version manuellement, sauf besoin particulier. Les distributions peuvent en effet rétroporter les correctifs de sécurité sur leurs propres versions.

Pour le problème IKEv1, inspectez également les configurations de vos tunnels. Si vous avez explicitement défini version = 1, vous connaissez déjà la réponse. Si vous utilisez une configuration automatique ou ancienne, vérifier les journaux de connexion permet généralement de déterminer rapidement quelle version d’IKE est négociée.

Et si votre infrastructure dépend encore d’IKEv1, la bonne réponse à long terme n’est probablement pas de conserver éternellement une vieille compilation de strongSwan.

C’est plutôt de commencer sérieusement à planifier la migration vers IKEv2.

Le VPN qui fonctionne depuis quinze ans n’est pas forcément celui qu’il faut garder quinze ans de plus

La sécurité des infrastructures possède un ennemi particulièrement efficace : le fameux « ça marche, on ne touche plus ».

Un tunnel VPN configuré il y a dix ou quinze ans peut continuer à accomplir parfaitement sa mission tout en reposant sur des choix techniques qui n’ont plus beaucoup de sens aujourd’hui. Et puisque personne ne voit directement le tunnel lorsqu’il fonctionne correctement, sa modernisation termine généralement très loin derrière « changer le logo de l’intranet » dans la liste des priorités.

strongSwan 6.1.0 force un peu la main.

Avec 11 vulnérabilités corrigées, la disparition progressive de vieux composants et IKEv1 désormais désactivé par défaut, le projet indique assez clairement la direction : les installations modernes doivent passer à IKEv2 et réduire leur dépendance envers des protocoles historiques.

Alors si votre VPN tombe après une mise à jour et vous affiche IKE version 1 not supported, vous pourrez toujours maudire Debian, Linux, strongSwan et probablement l’administrateur qui avait configuré le tunnel en 2009.

Mais peut-être que le vrai problème n’est pas la mise à jour.

Peut-être que votre VPN essayait simplement de vous dire depuis quinze ans qu’il aimerait prendre sa retraite.