Ce contenu a été rédigé par sgble qui a quitté le site.
Avez-vous entendu parler de VPN ? Après avoir entendu tant d’éloges à leur sujet, pensez-vous en avoir besoin vous aussi ou doutez-vous encore de son utilité dans votre cas ?
Il apparaît en effet difficile de ne pas perdre le nord1 face à ces nombreux boniments ornés de jargon technique impressionnant (intimidant ?).
Cet article a un but précis : passer en revue et questionner sur un plan technique et critique les affirmations les plus courantes des fournisseurs de VPN et des influenceurs qui en chantent les louanges. Ainsi conviendrait-il que j’avertisse dès maintenant les lecteurs quant à la teneur technique des propos qui suivent, lesquels pourraient paraître parfois jargonneux et, eux aussi, intimidants. Des efforts ont été faits pour que plusieurs niveaux de lecture soient possibles. Si certains points s’avèrent obscurs malgré ces efforts, je ne peux que vous encourager à poser des questions, voire ouvrir un sujet et ainsi bénéficier de la sagesse de la communauté
Mise en garde technique
Dans l’article suivant, deux présupposés sont faits pour alléger le propos :
- les couches de sécurité sont implémentées correctement : versions de TLS récentes, vérification des certificats systématique, utilisation de cipher suites et d’algorithmes réputés sûrs ;
- l’utilisation d’un VPN est jugée « sans fuite » : pas de DNS leaks ou de WebRTC leak.2
- 🥁 Aabu↩
- Un vieil article que j’ai écrit explique ce qu’est un DNS leak est comment le mettre en œuvre soi-même : DNS Leak: How it Works and How to Implement It (en anglais).↩
Qu’est-ce qu’un VPN ?
Cet article s’intéresse exclusivement aux offres de VPN commerciaux grand public dont il est question dans les publicités qui inondent les réseaux sociaux. Ainsi, tenons-nous en à une définition qui se borne à ce qui est généralement présenté.
Un VPN permet d’établir un tunnel entre votre machine et un serveur du fournisseur de VPN. Tout le trafic réseau (tous les paquets IP) passera par ce tunnel si bien que le serveur du fournisseur VPN sera votre point de sortie sur le réseau Internet. Les autres machines du réseau Internet verront donc ce point de sortie comme source de vos connexions, et non pas votre routeur (la « box ») fourni par votre fournisseur d’accès à Internet (FAI). Ce tunnel est chiffré de bout en bout, nous verrons ce que cela signifie en pratique.
Revues technique des louanges
Le VPN protégerait et sécuriserait vos données
Par « protéger » et « sécuriser », entendons-nous sur deux choses : protéger les données signifie qu’il n’est pas possible d’intercepter la communication (les données en transit) pour la lire (confidentialité) et qu’il n’est pas possible non plus de l’altérer pour détourner l’information à des fins malveillantes (authenticité). Les systèmes cryptographiques modernes en œuvre (correctement) dans les VPN permettent effectivement d’assurer la confidentialité et l’authenticité des données en transit dans le tunnel. Mais une question doit impérativement se poser pour apprécier les implications.
Ça protège. Mais ça protège quoi ou de qui ?
Le tunnel vous protège essentiellement de deux acteurs : le fournisseur d’accès à Internet (FAI) qui achemine vos données vers le reste de l’Internet et les autres machines qui pourraient partager le même réseau local (LAN) que votre machine.
Réseau local et partagé
Le réseau local est constitué des tous les appareils connectés (en filaire ou Wi-Fi) à une même box1. À la maison, le réseau local est supposément privé car seuls vos équipements sont sur ce réseau en principe de confiance. Mais la notion de réseau local s’étend aussi dans le cas d’une connexion Wi-Fi partagée au parc ou au café. Vous partagez alors le même réseau local que d’autres utilisateurs, lesquels ne peuvent pas être réputés dignes de confiance. Il en va de même avec l’entité qui possède et gère ce point d’accès (la café, la municipalité qui met du Wi-Fi dans le parc, etc.)
Au sein d’un même réseau local, il est possible de sniffer le trafic et d’intercepter les communications facilement, surtout en Wi-Fi partagé.
Mais d’après notre définition, cela n’est pas un problème avec le VPN : le tunnel sécurisé est établi entre votre machine et le serveur du fournisseur VPN. Les curieux partageant votre réseau local ne peuvent donc pas lire les communications chiffrées, ni les altérer à des fins malveillantes, ni savoir quels sites vous visitez.
Fournisseur d’accès à Internet (FAI)
Au delà de la box et du réseau local, le FAI est le transporteur de vos paquets IP (le trafic) émis ou reçus.
Il y a donc nécessairement accès afin d’effectuer son travail d’acheminement. À ce titre, même s’il n’est pas techniquement nécessaire d’inspecter le contenu des paquets (seules les métadonnées d’un paquet suffisent pour le router), il peut techniquement le faire, on parle alors de Deep packet inspection (DPI), et même altérer les paquets. Le DPI peut être mis en œuvre par un FAI pour diverses raisons :
- surveillance,
- ciblage publicitaire,
- censure,
- sécurité, etc.
Le tunnel chiffré enrayerait la moindre tentative de DPI.
Et HTTPS dans tous ça ?
Il est vrai qu’une simple couche HTTPS suffit à contrecarrer les attaques évoquées ci-dessus (inspection de paquets, altération des données en transit). Même sur une connexion Wi-Fi partagée on ne peut plus douteuse2, d’autres machines sniffant le trafic ne pourraient lire les données si HTTPS est mis en œuvre, cela valant aussi pour tout autre protocole TCP sur couche TLS3 (dont SMTPS, IMAPS pour vos emails). Cela nous amène donc à une question.
La généralisation de HTTPS (et TLS) rendrait-il l’utilisation d’un VPN superflue ?
S’il est vrai que quasiment tous les grands services sont accessibles uniquement en HTTPS depuis quelques années, il persiste encore quelques petits services en clair, des réfractaires malgré les incitations de plus en plus insistantes de la part des éditeurs de navigateurs Web.
Ici, nous pourrions ainsi penser que le VPN permettra au moins de protéger les données initialement en clair jusqu’à la terminaison du tunnel. Mais pas au delà : une fois sorti par le serveur du fournisseur de VPN, le trafic doit encore continuer sa route jusqu’à sa destination finale (le serveur du site que vous voulez visitez). Si ce trafic est originellement en clair, il le redeviendra aussitôt après avoir quitté le tunnel.
Pour cette raison, l’utilisation d’un VPN n’est pas un prétexte pour se passer des protocoles sécurisés comme HTTPS qui assurent la sécurité de bout en bout : de votre machine jusqu’au serveur final du site que vous visitez. Je ne peux donc que vous encourager à veiller à utiliser des protocoles sécurisé partout, VPN ou non.
Nous verrons dans la section suivante un autre aspect qui pourrait rendre l’utilisation d’un VPN pertinente malgré tout.
Le VPN permettrait de ne pas savoir où vous allez
Les métadonnées des paquets sont essentielles pour qu’ils arrivent à destination, c’est l’équivalent d’une étiquette collée sur un colis, laquelle indique plusieurs informations comme l’expéditeur et l’adresse de réception. Ces métadonnées ne peuvent être cachées, sinon le FAI ne peut simplement pas assurer sa mission. Ce serait comme confier un colis à La Poste sans dévoiler son adresse de destination.
Ces métadonnées sont des données. Elles peuvent être exploitées car elles constituent en elles-mêmes des renseignements, dont potentiellement sur les sites que vous visitez (leurs adresses IP). L’usage de HTTPS n’y changera rien.
Autre élément qui peut trahir vos destinations même en utilisant HTTPS : le DNS en clair. Le DNS est souvent cité comme un exemple de protocole qui n’est jamais chiffré. Cela est vrai dans la plupart des cas aujourd’hui, bien qu’il soit parfaitement possible de faire passer le DNS sur une couche sécurisée comme DNS over TLS ou encore DNS over HTTPS (pris en charge nativement par Firefox). Cela pourrait devenir la norme et des efforts semblent être faits dans ce sens. Espérons-le.
Connaître le contenu de vos requêtes DNS mettent en péril votre vie privée : il est aisé de connaître les sites que vous consultez (voire plus encore) en observant ce trafic-là.
Mais pour peu que les requêtes DNS passent elles aussi par le tunnel VPN, les équipements du réseau local et le FAI ne pourront donc pas savoir quels noms de domaine vous voulez résoudre. Il s’ensuit qu’il ne sera donc pas possible non plus de deviner aisément quel site vous comptiez visiter d’après vos résolutions DNS.
Quand même vous utiliseriez une méthode de résolution DNS sécurisée (disons DNS over HTTPS sous Firefox), il reste malgré tout un trou dans la raquette : le maudit SNI…
La section suivante est un peu technique, n’hésitez pas à la sauter si vous ne comprenez pas. Retenez cependant cela : malgré HTTPS (et TLS en général), il est possible de savoir quel site vous vouliez plausiblement visiter même s’il ne sera pas possible de savoir ce qui se dit entre ce site et votre machine par la suite (grâce au chiffrement).
Quand une session TLS s’établit, il y a un handshake qui permet de négocier certains paramètres et de générer les clefs de chiffrement à utiliser. Le client indique en clair le nom du serveur qu’il souhaite atteindre4. C’est le SNI: Server Name Indication. Or, ce SNI est en clair et il n’est pas vraiment possible de faire autrement5.
Regardons l’exemple d’un handshake TLS entre moi et un site Web proposant le HTTPS dans un outil d’analyse réseau (tel qu’un acteur malveillant pourrait utiliser) :
# tcpdump port 443 -v -A -n
12:26:08.645713 IP (tos 0x0, ttl 64, id 34468, offset 0, flags [DF], proto TCP (6), length 569)
10.8.42.54.38008 > 92.243.7.44.https: Flags [P.], cksum 0x75f3 (correct), seq 1:518, ack 1, win 502, options [nop,nop,TS val 1257528485 ecr 550319964], length 517
E..9..@.@.A.
..6\..,.x........T.....u......
J.\. .7\............ v!.....x.d~.v.d...$......./z.. .;......o..K.c..........N.."Q....".......+./.....,.0.
. ........./.5.............zestedesavoir.com..........
.............................h2.http/1.1..........3.k.i... fG....y...@..E..Z...E....0..K).....A.Qb....f<.
..'.^#K.....,`...e.>..v..b..P..8..f.y..".c;R.....$.!...+................................-........@....L.............................................................................).K.&. ..r..N6....;.....g..".......T.6}..X..! .D....w.o.O....(.$.$.j....Xs./O.
Regardez bien et apercevez ce zestedesavoir.com
en plein milieu. Même si les données qui suivront seront parfaitement chiffrées et inexploitables, ce hadnshake permet quand même aux acteurs (FAI et utilisateur du réseau partagé) de savoir que je vais sur https://zestedesavoir.com/.
Ici, un VPN empêcherait que ce SNI soit visible par votre FAI. En effet, tout le trafic passant par le tunnel chiffré, même ce qui est en clair (dont le SNI) serait protégé. Néanmoins, le même avertissement que tout à l’heure s’applique encore : à la fin du tunnel, ce SNI est en clair à nouveau quand il sort du serveur du fournisseur VPN (et le fournisseur du VPN peut le voir, ce SNI).
Première conclusion
Le VPN peut effectivement protéger vos données vis-a-vis de votre FAI et des autres utilisateurs d’un même réseau local. Y compris ce qui est en clair de base. Il permet, en plus de protéger les communications (ce que faisait déjà HTTPS), de se prémunir contre la surveillance du FAI qui ne peut pas savoir où le visiteur va pendant ses navigations.
Mais gardons ce qui suit à l’esprit :
- les données sont livrées à elles-mêmes une fois sorties du tunnel VPN. Entre le serveur VPN et le serveur cible que vous voulez visiter, il y a encore un peu de route pendant laquelle des données (dont le SNI) peuvent être inspectées par des opérateurs que vous ne connaissez même pas (c’est le cas aussi sans utiliser de VPN) ;
- le FAI ne saura pas quels sites vous visitez, certes. Mais le fournisseur du VPN, lui, pourra voir tout ce que le FAI aurait pu voir si vous n’utilisiez pas de VPN. Le fournisseur VPN voit le SNI et les requêtes DNS (si non chiffrées), il voit donc où vous allez et il peut prendre des notes comme l’aurait fait votre FAI ;
- l’utilisation d’un VPN ne vous dispense pas d’utiliser des protocoles sécurisés tels que HTTPS, SMTPS ou encore IMAPS pour accéder à vos service. Si vous n’acceptez pas que votre FAI puisse lire vos secrets, alors vous ne devriez pas non plus laisser le fournisseur VPN les lire.
Vous avez donc échangé votre FAI contre votre fournisseur VPN. Les pouvoirs de surveillance que vous arrachez au FAI, vous les octroyez aussitôt au fournisseur VPN. Soyez donc bien conscients que vous gagnez au change que si le fournisseurs VPN peut être raisonnablement réputé plus sûr que votre FAI.
Le VPN vous rendrait anonyme
Cela est peu probable.
Il est vrai que, via un VPN, un site Web que vous visitez ne pourra pas connaître votre adresse IP originale, laquelle pourrait servir à vous identifier personnellement.
Mais le fait est que l’on n’a nullement besoin de connaître votre « vraie » adresse IP pour vous identifier. Il y a une panoplie de techniques plus moins simples pour cela : cookies, fingerprinting de votre navigateur ou tout bêtement le fait d’être connecté à vos services habituels pendant votre navigation avec les cookies tiers.
Si vous voulez être anonyme, le VPN ne sera pas la réponse technique adéquate de façon générale.
Le VPN protégerait contre les « hackers », les « brouteurs » et les sites malveillants
Nous venons de voir qu’un VPN pouvait éventuellement protéger la confidentialité vis-a-vis d’un FAI trop curieux. Mais la protection vis-a-vis des acteurs malveillants n’a pas été abordé
Dans le cas général, non hélas. Les attaques de ce genre reposent le plus souvent sur le Social Engineering. Un VPN n’est pas une réponse technique à ce genre de problèmes. De façon générale, il n’y a d’ailleurs pas de solution technique à cela.
Parmi les failles classiques et techniques pouvant impacter l’utilisateur pendant la navigation, citons la faille XSS ou la ré-utilisation de cookie via CSRF. L’utilisation d’un VPN ne changera ici rien au bon déroulement de l’exploitation de telles failles. Les contre-mesures existent mais se trouvent ailleurs.
Le VPN protégerait vos appareils
Non. Ce n’est tout simplement pas le travail d’un VPN. Votre appareil peut présenter une vulnérabilité exploitable indépendamment de l’utilisation d’un VPN.
Ironiquement, il est intéressant de noter qu’une machine connectée à un VPN augmente sa surface d’attaque : une interface réseau en plus, fût-elle virtuelle, c’est une porte d’entrée en plus sur votre machine. Prions pour qu’il n’y ait donc pas de compromission des serveurs de votre fournisseur VPN, ni de mauvais réglage de sa part.
Le VPN permettrait de se connecter avec l’adresse IP d’un autre pays
Oui, c’est vrai. Le VPN permet donc de contourner par exemple le géo-blocage ou la censure. Précisons néanmoins que de tels contournements peuvent parfois aller à l’encontre des CGU/CGV du service mettant en place ces mesures.
Ajoutons aussi à cela qu’il n’est pas spécialement difficile de différencier une connexion « réelle » d’une connexion utilisant un VPN ou un proxy. L’usage des VPN pourrait se populariser au point où les services de vidéo à la demande soient assez motivés pour le contrer. Si cela arrive, il faut rester conscience qu’elles pourront sans doute le faire sans grande difficulté (diverses astuces permettent de deviner de façon plus ou moins fiable cela).
- Plus précisément, un même broadcast domain émanant d’un switch qui interconnecte tous les appareil du LAN entre eux. La box fait ici office de switch.↩
- En supposant que l’implémentation soit correcte et que le certificat soit bien valide. Si votre navigateur vous alerte d’un problème de certificat invalide quand vous tentez de vous connectez à un sites en HTTPS alors que vous êtes sur un réseau partagé : N’ACCEPTEZ SURTOUT PAS.↩
- Et TLS en général. HTTPS n’est ni plus ni moins que HTTP sur TLS, et il en est de même pour les autres protocoles TCP. Pour plus d’informations et savoir comment rendre n’importe quel service TCP accessible sur une couche TLS, j’ai rédigé le billet suivant : HAProxy et tout devient TLS ! .↩
- C’est comme l’indication d’un vhost via le header
Host
en HTTP, mais dans le protocole TLS.↩ - Une alternative avait été proposée et vaguement implémentée : ESNI (Encrypted SNI) mais ça ne semble pas avoir pris. Soyons patients et attendons de voir ce que ECH (Encrypted Client Hello) nous réserve à l’avenir.↩
Annexe : les VPN en général
Nous n’avons parlé que des VPN racontés selon les influenceurs des réseau sociaux. Laissez-moi, à mon tour vous parler de la véritable puissance des vrais VPN !
Si l’on s’en tient à une définition dérivée du nom VPN, on pourrait dire qu’il s’agit d’un dispositif permettant de créer un réseau de machines sans qu’il soit nécessaire pour autant de mettre en place une liaison physique (filaire ou sans-fil) entre eux. Ce qui nous servira de « câbles virtuels », ça sera une connexion déjà existante. La liaison est donc souvent logicielle (virtuelle). Pour réaliser cette prodigieuse chose, l’astuce est assez simple : encapsuler un protocole (IP ou Ethernet, typiquement) dans une couche transport reposant sur une liaison déjà existante.
Il est bien entendu possible de faire un VPN par dessus un autre VPN, et ainsi de suite. (attention, il y a un peu d'overhead, malgré tout)
Remarquez que je n’ai en aucun cas parlé de sécurité ici. Le chiffrement ou la sécurité en général n’est pas une caractéristique inhérente d’un VPN. Tant que vous fabriquez un réseau en vous appuyant sur un autre réseau sous-jacent, c’est déjà du VPN techniquement, qu’il y ait ou non du chiffrement (exemple : VXLAN, qu’il est alors possible de faire passer sur IPSec ou WireGuard si la sécurité est requise).
L’intérêt est souvent de faire un réseau privé étendu : avec un VPN, on peut faire comme si l’on avait un même réseau local sur plusieurs points séparés physiquement. Par réseau local, j’entends un même broadcast domain. OpenVPN (configuré en layer 2
) et VXLAN le permettent, par exemple. Conceptuellement, c’est comme si vous aviez un swicth virtuel branchés à plusieurs serveurs qui seraient absolument n’importe où physiquement. Puissant, n’est-ce pas ?
Un autre intérêt serait de permettre d’avoir un réseau caché et privé, lequel ne pourrait être routé que parmi les machines autorisées. Cela est très utilisé en entreprise où les services internes seront accessibles via le VPN et pas au delà. En bonus, cela permet aussi à des employés d’accéder à ce réseau privé sans pour autant être physiquement sur les lieux. Pour le télétravail, c’est plutôt intéressant. Dans ce cas, c’est comme si le serveur VPN était un routeur virtuel entre les machines.
Enfin, il est tout à fait possible de faire le pont entre un réseau virtuel et un réseau physique. Cela est appelé un bridge et cela permet d’acheminer du trafic sur une connexion déjà existante s’il n’est pas possible de router ses adresses IP directement depuis une certaine localisation. Cette technique est assez utilisées chez des opérateurs Internet qui n’ont pas forcément d’infrastructure physique présente dans une zone, mais qui veulent quand même faire passer leur trafic IP.
À noter que les VPN commerciaux grand publics ne permettent pas tout cela en général. Vous voyez qu’il s’agit ici plutôt de techniques de réseaux. Il faut le faire vous-même ou alors souscrire à une offre professionnelle.
Si l’aventure des VPN vous tente, utilisez le code apt install wireguard
ou apt install openvpn
et bénéficier de votre propre infrastructure VPN dès à présent ! Sans engagement !
J’espère que cette revue technique des affirmations habituelles vous aidera à faire mieux la part des choses afin de déterminer vos besoins réels.