Ce que le tunnel chiffre et ce qu'il laisse lisible

Votre tunnel est actif, un onglet affiche un cadenas vert, et une page HTTP simple dans un autre onglet prévient toujours que la connexion n'est pas sécurisée. Cette combinaison déroute les gens parce que les deux protections couvrent des distances différentes. Un VPN protège le trafic entre ses propres extrémités, et au-delà de la sortie le trafic redevient ordinaire. HTTPS protège une connexion jusqu'au site web. Mettre ces deux faits côte à côte explique la plupart des questions sur ce qu'un VPN cache réellement.

Ce que le tunnel couvre réellement

Entre le client et le pair VPN, un observateur voit des octets chiffrés plutôt qu'une requête lisible. Cela couvre le segment que le tunnel traverse, qui est généralement la partie que vous ne contrôlez pas. Cela ne s'étend pas au lien entre la sortie VPN et le site web, car le tunnel s'est terminé à la sortie. Les octets redeviennent lisibles à partir du moment où le tunnel se termine. Rien de tout cela n'est une mauvaise configuration.

La sortie est une machine qui déchiffre et transmet, ce qui est exactement le rôle d'un VPN. Tout ce qu'elle transmet lui est visible dans la forme où elle l'a reçu, donc une requête HTTP simple reste en clair à partir de la sortie.

Lisez cela comme une propriété plutôt que comme un défaut. Le chiffrement est limité à un chemin, et le chemin se termine là où le service commence.

Clés, nonces et intégrité en termes simples

Le trafic en cours est protégé par une cryptographie symétrique, et les deux extrémités dérivent ou obtiennent le matériel de clé pendant la poignée de main. Le chiffrement authentifié, décrit de façon générale par la RFC 5116, assure confidentialité et intégrité dans une seule construction. Le destinataire rejette les octets modifiés au lieu de simplement ne pas pouvoir les lire, et c'est la partie que les gens oublient quand ils croient que chiffrer signifie brouiller.

Les clés viennent de cet échange, pas du mot de passe saisi à la connexion. Le mot de passe authentifie une identité, puis le protocole établit le matériel de session. L'échange de clés éphémère assure la confidentialité persistante, de sorte qu'une session enregistrée reste illisible même si une clé de longue durée fuit plus tard.

Un grand nombre dans une spécification ne répond à aucune de ces questions, et comparer des nombres entre algorithmes sans rapport n'est pas un classement. Demandez plutôt ce que l'échange de clés apporte.

Où le tunnel se termine

L'extrémité qui termine le tunnel peut lire ce qu'elle transmet. C'est vrai aussi bien d'une passerelle d'entreprise que d'un fournisseur commercial ou d'un serveur auto-hébergé. C'est la conception, pas un défaut. Une cryptographie forte ne peut pas empêcher une extrémité compromise de lire le texte en clair qui lui arrive, car l'extrémité est là où la protection s'arrête.

HTTPS continue au-delà de ce point, c'est pourquoi un site peut être sûr sur un réseau hostile même sans VPN. Les deux protections se chevauchent sur le premier segment et une seule continue après la sortie.

C'est aussi pourquoi affaiblir la vérification du certificat pour faire fonctionner une connexion n'est pas un test du tunnel. Cela désactive une autre protection et vous laisse avec moins qu'au départ.

Pourquoi l'anonymat est un autre produit

Les adresses, le minuteur et le volume restent observables hors du tunnel. Un observateur peut voir que le trafic va vers une extrémité VPN, à peu près combien et quand. Le contenu peut être illisible alors que le schéma reste informatif.

Le fournisseur se trouve aussi ailleurs que votre propre réseau, ce qui est un changement d'observateur et non une suppression de l'observation. Les cookies, les connexions et les identifiants de compte fonctionnent exactement comme avant, car le tunnel n'a jamais promis de les modifier.

Choisissez un fournisseur selon sa politique de journalisation et sa juridiction si c'est l'exigence, puis lisez la politique elle-même. Les pages marketing répondent rarement à cette question d'une manière que quiconque peut vérifier.

Vérifiez le tunnel et le site séparément

Vérifiez d'abord le tunnel, pour savoir quelle protection vous testez. Vérifiez ensuite le transport propre au site et comparez les deux résultats au lieu de supposer que l'un implique l'autre. Un tunnel qui transporte du HTTP simple et un site qui sert du HTTPS font exactement ce pour quoi ils ont été configurés.

Exécutez les contrôles contre un hôte que vous êtes autorisé à tester, et lisez la sortie plutôt que le résumé.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

Quand le tunnel est actif et que le site est en HTTPS, vous avez deux protections sur le premier segment et une sur le second. Quand le site est en HTTP simple, le second segment est lisible par quiconque s'y trouve, y compris la sortie qui a transmis la requête. Savoir laquelle des deux manque, c'est tout le diagnostic, et cela demande deux commandes plutôt qu'un nouveau client.