HTTPS, DoH, ECH et un VPN cachent des choses différentes

Ajouter un VPN à un navigateur qui utilise déjà HTTPS, DoH et ECH n'empile pas trois protections en une ; cela change qui est en position d'observer quoi. Chaque mécanisme retire une partie différente d'un échange différent, et chacun laisse quelque chose derrière lui. La question utile n'est pas de savoir lequel est le plus fort, mais quel observateur vous cherchez à retirer, car la réponse décide si un tunnel aide du tout. Une comparaison des observateurs restants est plus utile qu'une liste de fonctions.

Quatre mécanismes, quatre observateurs

Commencez par les quatre relations et par la partie que chacune est conçue pour tenir à l'écart. Le tableau ci-dessous est celui que j'utilise en revue, parce qu'il force la conversation à nommer un observateur plutôt qu'une technologie.

La valeur du tableau est ce qu'il refuse de dire. Il ne classe pas les mécanismes et il n'affirme pas que les quatre ensemble retirent les quatre observateurs. Une application web en nuage qui termine déjà TLS à sa propre périphérie est protégée du réseau d'accès pour cet échange, et aucun tunnel n'améliore cette propriété précise. Ce qu'un tunnel peut changer, c'est quel réseau voit les paquets extérieurs et quel opérateur se trouve désormais sur le chemin.

Ce que HTTPS cache réellement

HTTPS protège l'échange de l'application entre le client et le point de terminaison que le certificat nomme. Il ne cache pas l'adresse de destination, il ne cache pas qu'une connexion a eu lieu, et il ne cache pas le nom sauf si ECH est en jeu. La validation du certificat fait partie de la protection, ce n'est pas une formalité autour d'elle.

Un VPN n'a pas besoin de terminer ce TLS, et une sortie de transfert ne doit pas être traitée comme le point de terminaison authentifié de l'application. Si une conception fait déchiffrer la sortie, c'est une autre architecture avec une autre déclaration de confiance.

Ce que DoH et ECH déplacent, et ce qu'ils laissent

DoH déplace l'échange DNS vers un résolveur HTTPS, ce qui signifie que ce résolveur voit vos requêtes au lieu du résolveur du réseau local. C'est un changement réel et borné : le résolveur choisi devient une partie qui peut corréler les requêtes avec les adresses auxquelles vous vous connectez ensuite, et c'est précisément la corrélation dont traite RFC 8484. Le transport chiffré ne rend pas le destinataire ignorant des requêtes auxquelles il répond.

ECH protège la partie sensible du ClientHello afin qu'un observateur passif sur le chemin ne puisse pas lire le nom de serveur visé. Cela dépend d'un déploiement compatible et de l'acceptation par le serveur et le réseau, et cela laisse d'autres canaux en place : les adresses de destination restent visibles, et le DNS peut encore révéler le nom.

L'autre chose que ECH ne fait pas, c'est de se prouver lui-même. Une connexion qui utilise TLS 1.3 n'est pas la preuve que ECH a été accepté, et un navigateur qui propose ECH à un serveur qui ne le prend pas en charge revient en arrière sans bruit. Vérifiez l'état réel de la connexion plutôt que de le déduire de la version du protocole.

C'est la forme générale de toute cette comparaison : chaque mécanisme se vérifie à sa propre couche, et aucun d'eux n'est vérifié par le succès d'un autre.

Ce qu'un VPN déplace, et ce qu'il ajoute

Lorsque le trafic web entre dans un VPN, le réseau d'accès voit l'échange extérieur avec le pair VPN au lieu des connexions individuelles des applications, et l'opérateur du VPN prend position sur le chemin ultérieur. C'est un déplacement de la frontière de confiance, pas sa suppression. L'opérateur voit désormais quelles destinations vous atteignez, même si le contenu reste chiffré de bout en bout. Savoir si c'est une amélioration dépend entièrement de laquelle de ces deux parties vous faites le moins confiance.

Gardez le HTTPS de l'application et la protection prévue du résolveur en place pendant que vous faites cela. Un tunnel ne remplace pas la validation du certificat, et désactiver les protections d'un résolveur parce que le trafic est tunnélisé retire un contrôle sans le remplacer.

Choisir à partir de l'exigence

Énoncez l'exigence réelle, car c'est elle qui décide de la conception. L'admission aux ressources privées, un point de sortie administré, une menace précise du réseau d'accès et l'autorisation des appareils sont quatre besoins différents avec quatre réponses différentes, et une entreprise qui n'utilise que des applications en nuage public doit encore décider de l'autorisation et du traitement des données. Des couches supplémentaires peuvent être appropriées sans être interchangeables. Une connexion plus compliquée n'est pas une mesure d'anonymat, et ce n'est pas un argument de sécurité en soi.

La spécification d'ECH, RFC 9849, mérite d'être lue pour ce que le mécanisme couvre et ne couvre pas, et elle est honnête sur les canaux qu'elle laisse tranquilles. Comparez les mécanismes selon l'observateur que chacun retire, notez cet observateur, puis décidez si la couche supplémentaire le vise. Si la réponse est que l'observateur était déjà hors de votre modèle de menace, le tunnel est un coût sans bénéfice.