Pourquoi et comment créer votre VPN maison

Julien Cirette |

Naviguer sur internet en sécurité demande une vigilance particulière. Si Apple s'efforce de protéger ses systèmes du mieux possible, il y a des situations où votre connexion est à risque, notamment lorsque vous vous connectez à un réseau Wi-Fi public.

Très schématiquement, votre fournisseur d'accès à internet (FAI) peut voir quels sites web vous consultez. Si vous faites confiance à votre FAI, il y a des raisons de se montrer vigilant quand vous vous connectez à un réseau Wi-Fi public : un malandrin pourrait réaliser une attaque man-in-the-middle et surveiller votre connexion.

UN VPN, c'est quoi ?

C'est là qu'intervient un Virtual Private Network, ou VPN. C'est l'équivalent d'un tunnel qui vous permet d'isoler les échanges entre votre appareil et un serveur. Ce tunnel est généralement chiffré, rendant théoriquement impossible la prise de connaissance de vos communications. De leur côté, les sites visités ne voient pas l'adresse IP de votre domicile, mais celle du serveur VPN.


Tags
avatar YetOneOtherGit | 

@Krysten2001

"Dans quel cas en utiliseriez vous un ?😉"

Pour un particulier ?

C’est cher payé pour pas grand chose en retour, je trouve.

Après chacun est libre de ses choix.

avatar Krysten2001 | 

@YetOneOtherGit

Oui en tant que particulier 😉

Pour tout ce qui vie privée,...

avatar YetOneOtherGit | 

@Krysten2001

"Pour tout ce qui vie privée,..."

Tu parles je suppose des services tiers.

Déjà il faut avoir confiance dans ce service tiers par qui transite ton trafic ce qui n’est pas évident (c’est pour cela que je parle en plaisantant de man in the middle payant)

En suite les bénéfices en terme de confidentialité sont très discutables aujourd’hui

Un de nos camarades a partagé cette vidéo un rien racoleuse mais qui après un survol rapide me semble assez proche de mes points de vue :

https://youtu.be/ckZGQ5cLIfs

avatar Krysten2001 | 

@YetOneOtherGit

Je vais la revoir 😉 mais à la fin il en recommande quelques uns quand même 🙃 Car depuis quelques temps comme ExpressVPN, ils mettent un chiffrement DNS en place. Il faut avoir confiance mais ne pensez-vous pas qu’il faut maximiser la confidentialité au maximum ?

avatar MSpock | 

@Krysten2001

Tu peux changer de serveurs des DNS pour des serveurs qui respectent plus la vie privée que ton FAI. Tu peux aller plus loin en hébergeant toi-même ton serveur DNS si tu n’as pas confiance. Et c’est gratuit ça.
Le VPN c’est un tunnel sécurisé, il est intéressant quand tu maitrises les 2 bouts du tunnel. Donc si tu as un VPN pour aller de ton tel à ton serveur à la maison ou de la maison à ton boulot(si tu fais confiance aux administrateurs de ton boulot) il y y’a un intérêt. Si c’est juste pour te sentir plus en sécurité, ça n’a pas d’intérêt.

avatar Krysten2001 | 

@MSpock

Juste question vie privée, mieux vaut rester chez son faille ou chez un autre tiers auquel on a plus confiance ?😉

Pour le dns, il y a Adguard il me semble.

avatar koko256 | 

@Link1993

C'est plutôt dns over https que dnssec qui permet de chiffrer les requêtes DNS.

avatar Link1993 | 

@koko256

Merci ! :)

Je ne sais plus les terminologies, si les solutions utilisées, mais je sais que ça existe, et que c'est utilisé par endroits.

avatar Sometime | 

@Link1993

La plupart du temps non c’est faux. HTTPS va aussi indiquer en clair le site auquel vous vous connectez, pas besoin d’aller pêcher dans les DNS pour cela.

avatar Link1993 | 

@Sometime

Je vais me renseigner sur le sujet plus en détail dans ce cas.
Il me semblait que seul la destination est transmise en clair.

Mais ça n'empêche pas qu'on se fera piquer ses identifiants sur un wifi public ^^

avatar Sometime | 

@Link1993

Regardez du côté des SNI - Server Name Indication.
Pour fonctionner correctement dans certains cas - par exemple pour les servers web hébergeant plusieurs sites - le serveur doit « savoir » ce que vous cherchez a atteindre (ne serait-ce que pour vous afficher le bon certificat qui va sécuriser la connection). Donc a la première connexion vers mettons google.com, même si vous utilisez des requêtes DNS chiffrées, un paquet de l’échange TCP initial avec google va présenter « google.com » en clair.

avatar Link1993 | 

@Sometime

Je pensais que c'était au serveur de déchiffrer ça, puis ensuite de rediriger vers le bon site présent sur la même machine (ou via proxy).

D'ailleurs, sur ce sujet, question debile.
Si j'ai un site (via Apache) accessible sur internet, et un autre avec un autre nom de domaine accessible seulement en local, peut-on envoyer une requête modifier pour que ça marche ?

Exemple : sur mon nom de domaine (OVH), j'ai désigné site1.exemple.com. Ce site hébergé sur mon serveur est donc accessible à l'extérieur (et c'est aussi celui affiché par défaut si on saisie l'IP). Est ce que je peux modifier une requête pour que le serveur Apache renvoie site2.exemple.com à la place, pourtant pas indiqué publiquement (et donc accessible que localement) ?

avatar Sometime | 

@Link1993

En fait il ya 3 notions:
- l’adresse IP
- l’en-tête HTTP « Host »
- le SNI

Dans le cas HTTPS l’en-tête Host, qui indique le site que vous voulez atteindre est en effet chiffrée. Ce qui veut dire que le serveur qui reçoit votre traffic ne peut pas y accéder avant de le déchiffrer (ahah logique).

Et c’est la que la bas blesse: a moins de n’avoir qu’un seul certificat à présenter, votre serveur ne va pas savoir quel certificat vous donner pour initier la connection chiffrée. D’ou le SNI, qui est a « l’extérieur » donc en clair et qui est utilisé pour initier votre HTTPS chiffré. Puis ensuite le serveur déchiffre, et accede a l’en-tête Host, et la envoie votre traffic la il doit aller selon la configuration choisie.

Sans SNI, le serveur ne peut que vous présenter le certificat par défaut, ce qui a de grande chance de provoquer une erreur, si celui-ci ne correspond pas au site que vous consultez. Si vous avez un seul site, avec un seul certificat, ça va, mais sinon vous aurez des soucis.

avatar Link1993 | 

@Sometime

J’ai du mal à comprendre l’idée du SNI... Plus d’info là dessus ? (Je vais en parallèle me renseigner sur le sujet, voir)

avatar Sometime | 

@Link1993

Imaginez que vous hébergiez deux sites sur une meme IP. machin.com et machine.com, chacun avec un certificat. Lorsque vous allez taper ca dans votre navigateur, vous allez obtenir l’IP via DNS puis essayer de vous connecter. Votre serveur Apache, comment peut-il savoir lorsqu’il établit la connection TLS, quel site vous voulez? Autrement dit comment peut-il vous présenter le bon certificat: c’est la même IP et puisque la connection TLS n’est pas encore établi, vous ne pouvez pas avoir l’info dans HTTP. C’est la que le SNI intervient. C’est en gros un champs dans TLS qui indique le fdqn que vous cherchez a atteindre.

En très gros, SNI est a TLS ce que l’en-tête « Host » est a HTTP.

avatar Link1993 | 

@Sometime

Ah, oui, j'avais donc bien la bonne idée en tête depuis le début alors (mais merci pour les explications techniques).

Mais ça veut dire que le man in the middle, ça sera l'hébergeur donc. Pas une personne sur un wifi publique du coup ^^

avatar Sometime | 

@Link1993

Pour le MITM on retombe sur la problématiques classiques de TLS, le SNI joue de ce côté assez peu. Mais si le serveur vois un SNI, un malandrin qui capture votre traffic sur un wifi public le verra aussi. De même que l’ISP et cætera: bref c’est juste pour illustrer que des informations sur votre navigations peuvent fuiter, meme avec HTTPS

avatar Sometime | 

@Link1993

Quand a votre situation, je crains que cela ne m’apparaisse pas clair. Que voulez-vous dire par public ou local?

avatar Link1993 | 

@Sometime

Ok, je vais expliquer mon cas.

J’ai un serveur DNS et Apache à la maison, et un nom de domaine publique chez OVH. Mon DNS reflète mon nom de domaine publique, plus quelques sous domaines persos (donc accessible que localement). En parallèle, j’ai des serveurs apache. La plupart accessible publiquement (le sous domaine est identique chez OVH et chez moi). Quelques uns ne le sont pas, pour raison de sécurité (une interface web pour ARIA2 en l’occurrence). Si je saisis le nom de domaine de ces sites accessibles localement seulement, à l’extérieur, ça ne marche pas puisque pas indiqué chez OVH, mais ça marche chez moi (mon DNS prends le relais).

Est ce que par une bidouille particulière, une personne a l’extérieur peut accéder à ce serveur Apache qui n’accepte que ce nom de domaine précis, mais qui n’existe pas en dehors de mon réseau local ? :)

avatar Sometime | 

@Link1993

Potentiellement oui. Déjà public et local en terme de DNS c’est biaisé. Ce n’est pas parce vous n’avez pas d’entrée DNS publique que qqn ne peut pas trouver vos IPs. A partir du moment ou vous avez une IP publique, qqn peut s’y connecter. Faites d’ailleurs le test vous même: récupérez l’IP et entrez la dans votre navigateur...

avatar Link1993 | 

@Sometime

Ah oui, totalement, mais si par exemple j'ai site1.exemple.com ouvert (via OVH), mais pas site2.exemple.com (qui est par contre enregistré sur le DNS local), ce dernier sera pas accessible à l'extérieur ?

A moins que oui, parce que le malandrin aura lui aussi créé son DNS perso, qui fera pointer son ordi vers la bonne IP, pour le site2.exemple.com

Je suppose que c'est ça ?

Et dans ce cas, faut absolument que je mette une règle dans apache pour le virtual host, et dire qu'il n'autorise les accès que depuis le réseau local...

avatar Sometime | 

@Link1993

Les DNS ne sont jamais qu’une façon de traduire un domaine en IP. Donc que cela soit enregistré ou pas n’empêche nullement quelqu’un d’accéder a l’IP. Après difficile d’aller plus loin sans connaître votre configuration. Mais dans le doute oui revoyez la peut-être...

avatar Xalio | 

@Link1993

Le problème du HTTPS (SSL en général) c’est que tu dépends du site qui l’implémente. Un site en HTTPS peut ne pas être secure si il a pas mis en place de la Forward secrecy, si des vieux protocoles sont utilisés ou même du SSL pinning ce qui est encore plus rare…

Le Man in the middle sur du HTTPS est possible.

avatar pakal | 

@Link1993

Intercepter du https est à la portée de n’importe quelle appliance de sécurité. (F5 BIGIP etc.)
Dans ma boîte le certificat tls de gmail est en réalité celui de ma boîte. Du coup tout ce qui transite en https est déchiffré côté entreprise et passe en clair. Le trafic est alors rechiffré par l’appliance côté internet.
Le but n’est pas d’espionner mais de vérifier qu’aucune info sensible ne sort. Mais il peut y avoir des dérives.

avatar Link1993 | 

@pakal

Heu.., mais on perd tout le principe d'un chiffrage sur HTTP du coup...

Ça veut dire que quelqu'un peut m'installer un truc en toute discrétion chez moi, et du coup, quand je me connecte sur le site de ma banque, récupérer mes identifiants même si je suis en HTTPS sur le site ?! Ça me paraît bizarre...

A moins que le certificat de votre boîte soit aussi autorisé de base sur vos PC. Mais à ce moment là, c'est indiqué dans la partie organisation du certificat...

Pages

CONNEXION UTILISATEUR