VPN TLS contre IPsec : les cinq champs qui méritent un examen

Classer les VPN TLS face aux VPN IPsec par famille de protocoles répond à une question que personne n’a posée, et cite généralement une construction que les deux familles ont abandonnée il y a des années. Ce qu’un évaluateur peut réellement apprécier, c’est la protection négociée, l’identité du pair, le modèle de client et le service exposé. Ces quatre éléments sont visibles dans un déploiement, et aucun ne découle de l’étiquette du produit. Demandez cinq champs et la conversation devient concrète.

Cinq champs, et l’étiquette n’en fait pas partie

Le premier champ est la version logicielle prise en charge, car une description de protocole sans version est une brochure. Le deuxième est la version de protocole négociée, qui décide quelles constructions sont même disponibles. Le troisième est la suite de protection, le quatrième la méthode d’authentification du pair et de l’utilisateur, et le cinquième l’étendue d’accès accordée par le produit après l’admission.

Une étiquette VPN SSL couvre au moins trois produits différents : un client réseau complet, un proxy applicatif et un portail hérité basé sur le navigateur. Ils exposent des services différents et échouent différemment, si bien que l’étiquette ne peut pas remplacer le champ d’étendue.

Ce que le chiffrement authentifié change réellement

TLS 1.3 impose le chiffrement authentifié, ce qui retire du protocole la construction MAC-then-encrypt plus ancienne au lieu de la laisser facultative. IPsec ESP dispose de suites à chiffrement authentifié depuis tout aussi longtemps, avec AES-GCM défini dans sa propre RFC. Dans les deux familles, la garantie vient de la suite négociée et non du nom de famille, ce qui explique pourquoi la liste des champs commence par une version. Un évaluateur qui ne peut pas nommer la suite n’a rien à évaluer.

C’est pourquoi la comparaison historique est trompeuse. Un déploiement figé sur une ancienne version de TLS avec une suite CBC et un autre qui exécute TLS 1.3 avec une suite AEAD ne présentent pas la même posture de sécurité, même si les deux sont des VPN TLS. La même division existe côté IPsec entre une suite ESP moderne et une combinaison héritée.

Lisez les valeurs négociées plutôt que la configuration que vous aviez prévue. Les commandes ci-dessous montrent ce sur quoi un point de terminaison actif et un tunnel actif se sont réellement accordés.

openssl s_client -connect vpn.lab.example:443 -tls1_3 -brief
ip xfrm state
swanctl --list-sas

Si le point de terminaison refuse de négocier TLS 1.3, c’est un constat et non une préférence. Si le tunnel liste une suite que vous n’attendiez pas, la configuration qui compte est celle que les pairs ont choisie, pas celle du modèle.

L’identité du pair est une question distincte

Un chiffrement sans pair vérifié protège le trafic des observateurs et le remet à quiconque a répondu à la connexion. L’authentification du pair demande quelle identité est attendue, quel matériel de confiance la valide, et comment le client se comporte quand la réponse ne correspond pas. Une chaîne de certificats, une clé épinglée et un secret prépartagé sont trois réponses différentes avec trois coûts opérationnels différents.

Posez ensuite les mêmes questions sur l’utilisateur ou l’appareil. Une passerelle qui authentifie la machine et admet n’importe quel utilisateur, ou l’inverse, a une posture précise qui devrait être écrite plutôt que supposée. Les autorisations de ressources appliquées après l’admission font partie du même champ, car l’authentification n’est pas l’autorisation.

Préserver les contrôles de nom d’hôte et de certificat importe plus que la familiarité de la fenêtre de connexion. Un client configuré pour ignorer la vérification a supprimé la seule étape qui distingue votre passerelle d’une imitation convaincante.

La frontière que le produit expose

Un portail sans client relaie certaines opérations applicatives via la passerelle, si bien que l’utilisateur atteint une interface plutôt qu’un réseau. Un client en tunnel complet transporte ce que ses routes et sa politique de filtrage sélectionnent, ce qui représente une surface bien plus grande. Comparer les deux par la force du protocole passe à côté de la différence dans ce qu’un attaquant peut atteindre à travers eux. L’un expose une interface applicative, l’autre un réseau routé, et les deux exigent des examens différents.

Demandez quel service est exposé, quelles opérations sont autorisées et sur quoi la passerelle elle-même écoute. Une interface d’administration joignable à la même adresse que le portail utilisateur est un constat de déploiement, et aucun choix de protocole ne le compense.

L’étendue par application réduit encore la surface, et elle change aussi le comportement en cas de défaillance quand le tunnel tombe. Une conception qui suppose une portée en tunnel complet cède de façons qu’une conception par application ne connaît pas, et la charge de support suit.

Décidez l’issue de défaillance et le cycle de vie

Ce qui se passe lorsque l’authentification ou la protection n’est pas disponible est une décision de politique qui relève de l’examen. Une issue bloquée et un repli direct non annoncé ont des conséquences différentes, et la différence est invisible dans une liste de fonctionnalités. Énoncez le comportement attendu à côté de la ressource qu’il protège.

Incluez le cycle de vie des correctifs et du support de la passerelle, ses fonctionnalités externes activées et le chemin de mise à jour des clients. Un choix de protocole correct ne rend pas sûr un service mal déployé, et la plupart des incidents se situent dans cet écart plutôt que dans la suite.

Écrivez les cinq champs, la politique de défaillance et le responsable du cycle de vie sur une page. Cette page est un examen ; une comparaison de familles de protocoles est une opinion.