Établir une connexion VPN sur un café WIFI en toute sécurité?
Sur mon ordinateur portable de travail, je crée régulièrement une connexion VPN que j'utilise pour le bureau à distance de notre serveur Web. Est-ce sûr de le faire dans un café où des personnes aléatoires sont connectées au même réseau wifi?
Oui, une connexion VPN crypte la connexion entre votre ordinateur et l'hôte VPN distant. La connexion ressemblerait à du charabia pour quiconque flairant le trafic, que ce soit dans le café ou sur Internet. Il convient de noter que la même chose s'applique à tout contenu envoyé via HTTPS même si vous n'utilisez pas de VPN.
Il convient également de noter que si vous utilisez la version actuelle de Microsoft Terminal Services (c'est-à-dire un bureau distant), la connexion VPN n'est même pas strictement nécessaire (du point de vue de la sécurité) car la connexion au bureau distant elle-même est également cryptée. Notez que ce paramètre peut être éventuellement réduit par la configuration administrative sur le réseau, donc le VPN n'est toujours pas une mauvaise idée.
Comme cela a déjà été dit - il est "sûr" d'utiliser un VPN sur un réseau sans fil public. Le VPN utilise des certificats pour établir un flux de données chiffré entre votre ordinateur et le serveur VPN. Vous pouvez utiliser un outil tel que wirehark pour vérifier cela. Cependant, je pense qu'il y a une possibilité d'insécurité au moins en théorie. Quelqu'un POURRAIT créer un faux point d'accès avec le même SSID que le vrai point d'accès et effectuer une attaque de l'homme du milieu - pour le VPN SSL de toute façon. Vous devriez obtenir un signal plus fort du faux AP pour que votre ordinateur choisisse celui-là plutôt que le vrai.
Voir le lien suivant pour plus de détails: Atténuation des méthodes d'attaque SSLStrip sur le VPN SSL Secure Access
En ce qui concerne la réponse de @AJ Henderson disant que les VPN peuvent ne pas être nécessaires pour la "version actuelle des services terminaux", vous devez savoir que même si le client est "le plus récent", un paramètre AD dans la stratégie de groupe peut affaiblir la sécurité et créer des scénarios Wifi peu sûr. Ceci est souvent effectué en tant que compromis pour permettre une fonctionnalité plus large.
Cela dépend vraiment du type de VPN que vous utilisez. Il devrait être configuré correctement des deux côtés (client et serveur, lorsque cette terminologie est applicable).
Certains serveurs PPTP ne fournissent aucun cryptage par défaut. De plus, vous devez vous assurer que vous utilisez la forme d'authentification appropriée (voir cet avis par exemple).
OpenVPN et IPsec (dans certains cas) utilisent des certificats X.509 pour authentifier le serveur (au moins). Cela souffrirait en partie des mêmes problèmes de PKI qui affectent HTTPS.
Vous devez vous assurer de vérifier correctement le certificat de la partie distante lors de la connexion (comme toujours avec les certificats); plus précisément, il doit vérifier que le certificat est approuvé et que son nom correspond à ce que vous recherchez. Les implémentations correctes doivent effectuer ces vérifications.
Vous pouvez également rencontrer le problème de CA malhonnête/compromis, mais je pense (espérons) que c'est plutôt rare. Dans le doute, réduisez la liste des autorités de certification approuvées sur votre machine si vous le pouvez.
IPsec avec un secret partagé. Cela peut être correct, tant que le secret partagé est plus secret que partagé. La connaissance de ce secret partagé peut permettre à un MITM de se faire passer pour le serveur (les liens sur cette page devraient également être intéressants).
Plus l'organisation est grande, plus il semble difficile de garder ce secret partagé suffisamment secret. Une recherche rapide des instructions VPN pour diverses universités semble indiquer que certains de ces secrets sont réellement rendus publics.
Malgré les problèmes de PKI, une solution basée sur un certificat rendrait plus difficile l'emprunt d'identité du serveur, car la clé privée correspondante du certificat ne serait partagée avec aucun utilisateur.
Donc, oui, un VPN peut vous protéger sur un réseau non fiable (au moins dans la mesure du réseau VPN distant), mais comme tout, il doit être configuré de manière appropriée.
Le VPN répond à vos besoins tant que les conditions suivantes sont remplies:
- Le nœud d'entrée VPN est authentifié par vous par exemple avec un certificat mis à jour
- Le certificat est sécurisé (il y a des problèmes avec les certificats, à savoir que le signe des certificats MD5 s'est avéré faible)
- Le mécanisme d'authentification du VPN est sécurisé (il a été signalé quelques problèmes avec certains mécanismes d'authentification à savoir MS-CHAP v2)
- Le mécanisme de cryptage des canaux est sécurisé (je ne suis pas au courant des failles connues)
Cela dépend de la configuration de votre VPN. Si votre client vérifie l'identité du serveur, par exemple à l'aide de certificats, alors oui. Si ce n'est pas le cas, vous pouvez toujours être MITM-ed.
1er risque: OS
Le premier point dont dépend la sécurité de votre solution proposée est la sécurité de votre OS qui est le point de départ de votre VPN.
Trop d'administrateurs ont tendance à oublier que l'utilisation d'un VPN pour accéder au réseau de son entreprise à partir d'un système d'exploitation faible est avant tout un risque pour la sécurité, et un risque majeur car une connexion entrante VPN est généralement classée comme fiable (sur le pare-feu de l'entreprise, à l'entreprise IPS, partout).
Voici un scénario de réalité courante: votre ordinateur est hébergé par un enregistreur de frappe. (Retour d'expérience réel: le chiffre habituel est supérieur à 1. Contrôle de l'utilisateur final avec une solution VPN: le chiffre habituel est inférieur à 1).
2e risque: circulation à côté du tunnel
Un VPN correctement configuré devrait bloquer la visibilité d'Internet via un trafic non crypté (c'est-à-dire une IP normale). Tout doit passer par esp (50) ah (51 maintenant pratiquement plus utilisé) ou 443/tcp/IP aka https.
Scénario de réalité: votre configuration VPN est en place mais le trafic sur la connexion sans fil chevet le tunnel est ouvert et rien sur le système ne le contrôle, et l'administrateur n'est pas suffisamment informé du réseau pour le voir au début.
Je suppose que vous ne tapez pas tcpdump -i en1 chaque fois que vous démarrez un VPN sur une interface nommée en1 pour vérifier que 53/udp/IP, 67/udp/IP… Inondent toujours à côté de l'entrée du tunnel :) et pas seulement 500/udp/IP.
Je suppose que vous ne vérifiez pas avec arp -a si un voisin est déjà connecté à votre PC dans l'environnement Wi-Fi.
3e risque: certificats acceptés par magie
Sur la plupart des systèmes d'exploitation, les utilisateurs, même les administrateurs et même les administrateurs conscients de la sécurité, ont tendance à faire confiance à la fonction automagique d'accepter un certificat distant. Cette fonction est cachée dans les navigateurs et parfois dans le système d'exploitation lui-même. Une confiance que vous ne vérifiez pas est magique. C'est un risque.
Lorsque cette magie implique que vous devez d'abord lancer Internet Explorer pour construire votre VPN, cela vaut une vie pleine d'investigation et d'horreur.
Lorsque vous vous connectez avec votre entreprise sur un VPN construit au-dessus d'une connexion https, votre entreprise doit vous forcer à vérifier le certificat de votre entreprise pour vous assurer que vous n'en utilisez pas un qui est présenté par un faux serveur Web au sein de votre Wi -Quartier Fi. Vous devriez avoir l'empreinte digitale du certificat de votre entreprise sur un document indépendant que vous pouvez vérifier dans n'importe quelle situation. Cette connexion ne doit pas être construite sur magic trust.