web-dev-qa-db-fra.com

Quelle est la différence de sécurité entre une connexion VPN et SSL?

Je voudrais concevoir une application client-serveur où le serveur est placé sur Internet. Je suppose que je pourrais configurer la connexion client-serveur en utilisant VPN (utilise-t-il IPSec?) Ou en utilisant une connexion SSL (éventuellement https). Quelles sont les différences entre VPN/IPsec et SSL/https pour sécuriser une connexion client-serveur sur Internet?

65
Jonas

VPN signifie "réseau privé virtuel". Il s'agit d'un concept générique qui désigne une partie d'un plus grand réseau (par exemple Internet dans son ensemble) qui est logiquement isolé du plus grand réseau par des moyens non matériels (c'est ce que signifie "virtuel"): ce n'est pas que nous utilisons des câbles et interrupteurs; l'isolement est plutôt effectué grâce à l'utilisation de la cryptographie.

SSL (maintenant connu sous le nom de TLS) est une technologie qui prend un support de transport bidirectionnel et fournit un support bidirectionnel sécurisé. Il nécessite que le support de transport sous-jacent soit "principalement fiable" (lorsqu'il n'est pas attaqué, les octets de données sont transférés dans l'ordre, sans perte ni répétition). SSL fournit la confidentialité, l'intégrité (les modifications actives sont détectées de manière fiable) et une certaine authentification (généralement l'authentification serveur, éventuellement l'authentification client-serveur mutuelle si vous utilisez des certificats des deux côtés).

VPN et SSL ne sont donc pas du même niveau. Un VPN implémentation nécessite un peu de cryptographie à un moment donné. Certaines implémentations VPN utilisent réellement SSL, résultant en un système en couches: le VPN transfère les paquets IP (du réseau virtuel) en les sérialisant sur une connexion SSL, qui utilise elle-même TCP comme moyen de transport, qui est construit sur des paquets IP (sur le réseau physique non protégé). IPsec est une autre technologie qui est plus profondément intégrée dans les paquets, qui supprime certaines de ces couches, et est donc un peu plus efficace (moins de surcharge de bande passante). D'un autre côté, IPsec doit être géré assez profondément dans le code réseau du système d'exploitation, tandis qu'un VPN basé sur SSL n'a besoin que d'un moyen de détourner le trafic entrant et sortant; le reste peut être vers le bas dans un logiciel de niveau utilisateur.

Si je comprends bien votre question, vous avez une application où certaines machines doivent communiquer sur Internet. Vous avez des exigences de sécurité et envisagez d'utiliser SSL (sur TCP sur IP) ou éventuellement HTTPS (qui est HTTP sur SSL, sur TCP sur IP), ou mettre en place un VPN entre le client et le serveur et utiliser "plain" TCP dans ce réseau privé (le but du VPN est de vous donner un réseau sécurisé où vous n'avez plus à vous soucier de la confidentialité) . Avec SSL, votre code de connexion doit être conscient de la sécurité; d'un point de vue de la programmation, vous n'ouvrez pas une connexion SSL comme si c'était "juste un socket". Certaines bibliothèques le rendent relativement simple, mais quand même, vous devez gérer la sécurité au niveau de l'application. En revanche, un VPN est configuré au niveau du système d'exploitation, de sorte que la sécurité ne se situe pas entre votre application sur le client et votre application sur le serveur, mais entre le système d'exploitation client et le système d'exploitation serveur : ce n'est pas le même modèle de sécurité, bien que dans de nombreuses situations la différence ne soit pas pertinente.

En pratique, un VPN signifie qu'une étape de configuration est nécessaire sur le système d'exploitation client. C'est assez invasif. L'utilisation de deux applications basées sur VPN sur le même client peut être problématique (en termes de sécurité, car le client agit alors comme un pont qui relie deux VPN qui devraient nominalement être isolés l'un de l'autre, et aussi dans la pratique, en raison de collisions d'adresse espace). Si le client est un client, le faire configurer correctement un VPN semble être une tâche impossible. Cependant, un VPN signifie que les applications ne doivent pas être conscientes de la sécurité, ce qui facilite grandement l'intégration de logiciels tiers dans votre application.

77
Thomas Pornin

Les deux ont des problèmes de sécurité s'ils ne sont pas configurés correctement. Mais commençons d'abord par quelques définitions:

Cisco a une bonne définition d'un VPN:

Le VPN peut prendre plusieurs formes. Un VPN peut être entre deux systèmes d'extrémité, ou il peut être entre deux ou plusieurs réseaux. Un VPN peut être construit à l'aide de tunnels ou de chiffrement (sur pratiquement n'importe quelle couche de la pile de protocoles), ou les deux, ou bien construit à l'aide de MPLS ou de l'une des méthodes de "routeur virtuel". Un VPN peut être constitué de réseaux connectés au réseau d'un fournisseur de services par des lignes louées, Frame Relay ou ATM, ou un VPN peut être composé d'abonnés d'accès à distance se connectant à des services centralisés ou à d'autres abonnés d'accès à distance. https://www.Cisco.com/c/en_in/products/security/vpn-endpoint-security-clients/what-is-vpn.html

Quant à SSL:

SSL (Secure Sockets Layer), également connu sous le nom de TLS (Transport Layer Security), est un protocole qui permet à deux programmes de communiquer entre eux de manière sécurisée. Comme TCP/IP, SSL permet aux programmes de créer des "sockets", des points de terminaison pour la communication et d'établir des connexions entre ces sockets. Mais SSL, qui est construit au-dessus de TCP, ajoute la capacité supplémentaire de cryptage. http://www.boutell.com/newfaq/definitions/ssl.html

En ce qui concerne votre question, la principale différence est que SSL utilise souvent le navigateur pour crypter les données entre l'utilisateur final et le serveur, et est couramment utilisé pour les zones de sites Web qui nécessitent la protection de la confidentialité et de l'intégrité des données.

VPN/IPSEC nécessite un logiciel client VPN spécifique et sert généralement à fournir un accès à distance aux systèmes ou réseaux. Il y a aussi la possibilité d'opter pour L2TP ou L2F au lieu d'IPSEC.

Cependant, les VPN SSL deviennent de plus en plus répandus comme moyen de fournir un accès aux réseaux/systèmes via le navigateur Web. Cette approche présente de nombreux avantages car elle utilise le navigateur Web commun pour activer la connexion sécurisée. La granularité de cette approche est également un bon moyen de contrôler les accès à des applications spécifiques.

Quant aux problèmes de sécurité -

SSL -

  • Des cyphers de sécurité faibles pourraient conduire à la possibilité de mener des attaques de type homme du milieu contre l'utilisateur final, entraînant une perte de confidentialité/intégrité des données.

    • Un mélange mal configuré de contenu HTTP/HTTPS pourrait également entraîner une perte de confidentialité/intégrité des données.

IPSEC -

15
David Stubley

Quelques très bonnes réponses ici, je ne répéterai pas ce qui a déjà été dit.
Cependant, un point que j'ai trouvé manquant - SSL est beaucoup plus facile à configurer sur une base ad-hoc, surtout si vous n'avez pas besoin de certificats clients.
IPsec, en revanche, nécessite toujours des certificats clients (en supposant une configuration normale et typique), et il existe également d'autres difficultés dans la configuration et la distribution initiales.

En tant que tel, IPsec est généralement plus adapté à un réseau contrôlé, et moins sur Internet sauvage et sauvage inconnu. Voir plus d'informations sur cette autre question: " faits IPsec (Internet Protocol Security) ".

Ainsi, pour revenir à votre question réelle, dans presque tous les cas où vous mettez le serveur sur Internet, vous ne vous attendriez pas à ce que vos utilisateurs se connectent à l'aide d'un VPN. (Des exceptions existent, bien sûr.)
. réutiliser ...)

7
AviD

Envisagez-vous ces options pour créer un VPN sécurisé? SSL est généralement plus facile à déployer et mieux pris en charge pour un type de VPN de bureau à réseau, comme lorsqu'un employé à domicile se connecte au réseau d'entreprise. Si vous effectuez un déploiement plus complexe, tel qu'un VPN chiffré de réseau à réseau (par exemple, entre deux organisations différentes), IPSEC fournira un meilleur contrôle et davantage d'options de personnalisation.

Il y a un bon livre blanc sur le sujet par Juniper Networks, bien qu'il puisse être biaisé par rapport aux points forts de leurs produits.

5
Eugene Kogan

Eh bien, la différence est un peu comme la différence entre un cercle et un carré (les deux sont des formes, mais diffèrent considérablement). Ils sécurisent tous les deux les communications, mais le font à différents niveaux et de différentes manières. IPSEC est le chiffrement et l'autorisation filaires tandis que SSL est spécifique à l'application.

IPSEC dispose d'un contrôle d'accès, contrairement à SSL.

Pouvez-vous être plus précis avec ce que vous essayez de comprendre?

2
Steve

Cela pourrait être une réponse très longue, mais je vais essayer la courte.

Lorsque vous utilisez https, votre navigateur (agit comme un client SSL) ne crypte que cette connexion au serveur Web.

Lorsque vous utilisez un VPN, vous avez besoin d'un client spécial et établissez un tunnel entre le client et le serveur. Ensuite, vous pouvez configurer le trafic passant par le tunnel. Cela peut être tout ou simplement votre trafic http.

Lorsque vous souhaitez uniquement configurer une application client/serveur pouvant communiquer avec http, la solution la plus simple devrait être le trafic https, lorsqu'il doit être chiffré. Il est beaucoup plus compliqué de configurer un VPN et de le maintenir.

2
Christian

Cela dépend de votre modèle de menace, de la nature du protocole client-serveur dont vous avez besoin et de vos clients.

Est-ce destiné à des utilisateurs finaux peu avertis? Ensuite, utilisez SSL - à ce stade, la complexité du VPN désactivera simplement de nombreux utilisateurs potentiels.

Voulez-vous déployer le client en tant qu'application de navigateur (perahps avec javascript)? Ensuite, https/ssl semble être la voie à suivre.

Le serveur doit-il jamais notifier de manière asynchrone le client de quelque chose? Le HTTPS peut ne pas être ce que vous voulez (bien qu'il puisse être fait pour le faire).

Quel est le risque de phishing? S'il serait facile pour les attaquants de leurrer les gens en tant que MITM, SSL est probablement meilleur car il authentifie chaque serveur auprès du client. Un VPN typique, une fois configuré, n'aide pas l'utilisateur à éviter un attaquant qui a pénétré d'autres hôtes sur le VPN. Ce ne serait probablement pas un risque énorme, mais encore une fois, cela dépend de ce que vous faites.

Si vous déployez cela dans le cloud (à la fois client et serveur), vous pouvez obtenir un type de VPN presque gratuit, ce qui peut répondre à des menaces très simples.

2
nealmcb

Je suis loin d'être un expert en sécurité, mais je pense que la différence la plus importante entre les deux n'est pas dans les autres réponses.

Par VPN, la communication se fait de cette façon:

HTTP client <-[raw]-> VPN client
  <-[encrypted]-> 
VPN server <-[raw]-> HTTP server

Par HTTP, cela se passe comme suit:

HTTP client
  <-[encrypted]-> 
HTTP server

Ainsi, par VPN, les données non protégées peuvent circuler sur le réseau local des clients et sur le réseau local des serveurs. Si vous ne faites pas entièrement confiance à ces réseaux, il est judicieux d'utiliser HTTP. Sachez que le VPN et les paires client-client HTTP, serveur-serveur ne sont pas nécessairement sur des ordinateurs identiques, par exemple les routeurs peuvent être configurés pour être des serveurs ou des clients VPN.

Étant donné que ces technologies fonctionnent à un niveau différent, elles ne s'excluent pas mutuellement, vous pouvez donc utiliser les deux si vous voulez une autre couche de protection et cela ne vous dérange pas la baisse de performances qui l'accompagne ou vous pouvez simplement utiliser l'une d'entre elles, qui convient mieux à vos besoins. Pour autant que je sache, les deux technologies sont considérées comme sécurisées si elles sont correctement configurées.

0
inf3rno