Les VPNS sont-ils vulnérables à l'homme actif au milieu des attaques?
Je sais qu'avec SSL/TLS, les attaques man in the middle ne sont pas possibles. Par exemple, si Alice et Bob essaient de communiquer et que Trudy essaie d'exécuter un homme dans l'attaque du milieu, alors quand Alice obtient la clé publique de Bob (mais c'est vraiment Trudy qui trompe Alice), la clé publique ne correspondra pas avec le autorités de certification et ne fonctionnent donc pas.
Je sais qu'avec SSH, seule la première connexion à un serveur est peut-être ouverte à un homme actif en pleine attaque. En effet, lors de la première connexion, le client enregistre la clé publique du serveur dans le fichier $ HOME/ssh/known_hosts. Chaque connexion après cela vérifie ce fichier pour s'assurer que les clés publiques correspondent.
Mais comment fonctionne le cryptage VPN avec la configuration de la connexion? Les certificats sont-ils utilisés pour transmettre les clés symétriques comme dans SSL/TLS? Sinon, cela ne rend-il pas les VPN vulnérables aux attaques de l'homme actif au milieu lors des échanges de clés?
Afin de se protéger contre une attaque d'homme au milieu, au moins l'un des points d'extrémité de la communication doit avoir une connaissance préalable de l'autre point d'extrémité. Il appartient généralement au client de vérifier qu'il parle au bon serveur, car les serveurs ont tendance à permettre à n'importe quel client de s'y connecter. Le terme général pour le type d'infrastructure qui fournit cette connaissance préalable est infrastructure à clé publique .
Dans le cas de HTTPS, la connaissance préalable s'accompagne normalement de l'étape intermédiaire de autorité de certification . Un navigateur Web contient une liste prédéfinie de CA avec leurs clés publiques et accepte un site Web comme authentique s'il peut démontrer que sa clé publique a été signée par la clé privée une CA.
Dans le cas de SSH, la connaissance préalable vient normalement d'avoir préalablement contacté le serveur: le client enregistre la clé publique du serveur et refuse de continuer si la clé publique du serveur n'est pas celle enregistrée. (Cela existe également pour HTTPS avec épinglage de certificat .) Lors de la première connexion, c'est à l'utilisateur SSH de vérifier la clé publique.
Il n'y a pas de norme suivie par un logiciel VPN. Vous devez lire la documentation de votre logiciel VPN. Dans les déploiements en entreprise, il est courant de déployer le certificat de serveur sur les ordinateurs des employés en même temps que le logiciel VPN, ou d'exiger que l'employé établisse une première connexion au VPN depuis l'intérieur du réseau de l'entreprise où une attaque MITM n'est pas à craindre. Le certificat est ensuite stocké dans la configuration du logiciel VPN et le client VPN refusera de se connecter si la clé publique du serveur change.
Si vous déployez un service VPN pour votre propre usage ou pour celui de votre organisation, vous devez vous assurer de provisionner le certificat de serveur au moment de l'installation, avant de vous lancer dans la nature. Si aucun réseau sécurisé n'est disponible, vous devrez vous fier à un autre canal de communication pour envoyer le certificat. Il pourrait s'agir d'un e-mail, si c'est ainsi que vous identifiez les utilisateurs, mais il serait préférable de s'appuyer sur une infrastructure préexistante telle que les clés GPG (envoyer le certificat dans un e-mail signé) - ce qui bien sûr ne fait que déplacer le problème sur la façon de vérifiez la clé GPG.
Si vous utilisez un service VPN basé sur le cloud, ce service devrait vous fournir un moyen de vérifier leur certificat (par exemple, une page Web servie via HTTPS) et devrait documenter comment installer le certificat ou comment le vérifier lors de la première utilisation. Encore une fois, il n'y a pas un seul processus que tous les logiciels VPN suivent.
Les VPN protègeront contre de nombreux MiTM s'ils sont correctement configurés, mais pas tous. Un VPN protège généralement contre la plupart des MiTM entre son ordinateur et la passerelle du VPN, mais une fois que le message/le trafic a atteint sa destination, il n'est que semi-anonyme et pas `` entièrement anonyme '', ce qui signifie qu'il y en aura un ou (généralement +) plusieurs attaques pouvant infiltrer et modifier le contenu du trafic. De plus, PPTP, LT2P et WPA2 ont tous des failles connues qui peuvent les rendre vulnérables à la fois à MiTM et à d'autres attaques similaires. WPA2 est particulièrement vulnérable aux attaques par dictionnaire. Pour plus de lecture sur ce que j'ai écrit et pour ajouter des données/contexte, veuillez voir ci-dessous:
https://help.riseup.net/en/vpn/security-issues
Le premier lien est au point et facile à lire tandis que le deuxième lien fournit plus de détails.