Https empêche-t-il l'homme au milieu des attaques par serveur proxy?
Un client de bureau A se connecte au site Web W dans une connexion https
A --> W
Entre A et W, il y a un proxy G.
A --> G --> W
- Dans ce cas, G pourra-t-il obtenir le certificat que A a précédemment obtenu de W?
- Si G peut obtenir le certificat, cela signifie-t-il que G pourra déchiffrer les données?
Comment fonctionne HTTPS?
HTTPS est basé sur cryptographie à clé publique/privée. Cela signifie essentiellement qu'il existe une paire de clés: la clé publique est utilisée pour le chiffrement et la clé privée secrète est requise pour le déchiffrement.
Un certificat est essentiellement une clé publique avec une étiquette identifiant le propriétaire.
Ainsi, lorsque votre navigateur se connecte à un serveur HTTPS, le serveur répondra avec son certificat. Le navigateur vérifie si le certificat est valide:
- les informations sur le propriétaire doivent correspondre au nom du serveur demandé par l'utilisateur.
- le certificat doit être signé par une autorité de certification de confiance.
Si l'une de ces conditions n'est pas remplie, l'utilisateur est informé du problème.
Après la vérification, le le navigateur extrait la clé publique et l'utilise pour crypter certaines informations avant de les envoyer au serveur. Le serveur peut le déchiffrer parce que le serveur a la clé privée correspondante.
Comment le HTTPS empêche-t-il l'homme au milieu des attaques?
Dans ce cas, G pourra-t-il obtenir le certificat que A a précédemment obtenu de W?
Oui, le certificat est la clé publique avec l'étiquette. Le serveur Web l'enverra à toute personne qui s'y connectera.
Si G peut obtenir le certificat, cela signifie-t-il que G pourra déchiffrer les données?
Non. Le certificat contient clé publique du serveur Web. Le proxy malveillant n'est pas en possession de la clé privée correspondante. Donc, si le proxy transmet le vrai certificat au client, il ne peut pas déchiffrer les informations que le client envoie au serveur Web.
Le serveur proxy peut essayer de falsifier le certificat et fournir sa propre clé publique à la place. Cela va cependant détruire la signature des autorités de certification. Le navigateur vous avertira du certificat non valide.
Existe-t-il un moyen pour un serveur proxy de lire HTTPS?
Si l'administrateur de votre ordinateur coopère, il est possible qu'un serveur proxy renifle les connexions https. Il est utilisé dans certaines entreprises afin de rechercher des virus et d'appliquer des directives d'utilisation acceptable.
Un autorité de certification locale est configuré et l'administrateur indique à votre navigateur que ceci CA est digne de confiance. Le serveur proxy utilise cette autorité de certification pour signer ses certificats falsifiés.
Oh et bien sûr, l'utilisateur a tendance à cliquer sur les avertissements de sécurité.
En supposant que les utilisateurs ne cliquent pas sur les avertissements de certificat (et en supposant que vous exécutez un client non modifié), la réponse est: Non, le proxy ne peut pas déchiffrer les données .
Pour une explication détaillée de la façon dont HTTPS empêche un homme du milieu de décrypter votre trafic, consultez toute ressource standard sur SSL/TLS, par exemple,
P.S. Le certificat est des données publiques. Il contient la clé publique et le nom de domaine du serveur, dont aucun n'est secret. L'observation du certificat n'aide pas l'attaquant à décrypter les données. (Oui, le proxy peut observer le certificat, mais cela est inoffensif.)
De le blog technique de Philipp C. Heckel avec quelques modifications légères:
Alors que l'attaque du trafic HTTP non chiffré peut être effectuée sans avoir à traiter avec les certificats X.509 et les autorités de certification (CA), les connexions HTTPS chiffrées SSL chiffrent chaque demande et réponse entre le client et le serveur de bout en bout. Et parce que les données transférées sont cryptées avec un secret partagé, un intermédiaire (ou un proxy) ne peut pas déchiffrer les paquets de données échangés. Lorsque le client ouvre une connexion SSL/TLS au serveur Web sécurisé, il vérifie l'identité du serveur en vérifiant deux conditions: Tout d'abord, il vérifie si son certificat a été signé par une autorité de certification connue du client. Et deuxièmement, il s'assure que le nom commun (CN, aussi: nom d'hôte) du serveur correspond à celui auquel il se connecte. Si les deux conditions sont remplies, le client suppose que la connexion est sécurisée.
Afin de pouvoir renifler dans la connexion, le serveur proxy peut agir en tant qu'autorité de certification, mais pas très fiable: au lieu d'émettre des certificats à des personnes ou organisations réelles, le proxy génère dynamiquement des certificats vers le nom d'hôte nécessaire pour une connexion . Si, par exemple, un client souhaite se connecter à https://www.facebook.com , le proxy génère un certificat pour "www.facebook.com" et le signe avec sa propre autorité de certification. À condition que le client fasse confiance à cette autorité de certification, les deux conditions mentionnées ci-dessus sont remplies (autorité de confiance, même CN) - ce qui signifie que le client pense que le serveur proxy est en fait "www.facebook.com". La figure ci-dessous montre le flux de demandes/réponses pour ce scénario. Ce mécanisme est appelé proxy HTTPS transparent.
Pour que cette attaque fonctionne, il y a quelques conditions qui doivent être remplies:
- Serveur proxy comme passerelle standard (HTTP et HTTPS) : Pour le proxy HTTP et HTTPS, le serveur proxy doit bien sûr être capable d'intercepter les paquets IP - ce qui signifie qu'il doit être quelque part le long du chemin du paquet. La manière la plus simple d'y parvenir consiste à remplacer la passerelle par défaut de la machine cliente par l'adresse du serveur proxy.
- Trusted Proxy CA (HTTPS uniquement) : Pour que le proxy HTTPS fonctionne, le client doit connaître (et faire confiance!) L'AC proxy, c'est-à-dire la clé CA Le fichier doit être ajouté au magasin de clés de confiance du client.
Si vous souhaitez renifler de manière transparente les sockets SSL, vous pouvez essayer
SSLsplit, un proxy TLS/SSL transparent man-in-the-middle. Il existe de nombreuses façons d'attaquer SSL, mais vous n'avez pas besoin de faux certificats SSL, d'une autorité de certification non autorisée ou de variantes des attaques SSL man-in-the-middle de l'expert en sécurité Moxie Marlinspike. Pourquoi vous donner tant de mal alors que vous pouvez simplement acheter un proxy d'interception SSL, comme ProxySG de Blue Coat Systems ou leur appliance SSL Netronome récemment acquise pour faire le travail pour vous?
De Steven J. Vaughan-Nichols sur ZDNet (extrait):
Blue Coat, le plus grand nom du secteur de l'interception SSL, est loin d'être le seul à proposer l'interception SSL et la rupture dans une boîte. Jusqu'à récemment, par exemple, Microsoft vous vendait un programme, Forefront Threat Management Gateway 2010, qui pouvait également faire le travail pour vous. Avec un programme ou un périphérique proxy d'interception SSL en place, voici ce qui se passe vraiment:
Si votre entreprise a correctement configuré le proxy, vous ne saurez rien est éteint, car ils se sont arrangés pour que le certificat SSL interne du proxy soit enregistré sur votre machine comme certificat valide. Sinon, vous recevrez un message d'erreur contextuel qui, si vous cliquez sur pour continuer, acceptera le "faux" certificat numérique. Dans les deux cas, vous obtenez une connexion sécurisée au proxy, il obtient une connexion sécurisée au site extérieur - et tout ce qui est envoyé via le proxy peut être lu en texte brut. Oups.
Selon la configuration du réseau sur lequel vous vous trouvez, il peut être possible pour les administrateurs d'afficher le contenu des connexions HTTPS (et éventuellement des VPN).
Il est évidemment possible d'intercepter le trafic sur le réseau, mais le problème habituel est qu'ils ne peuvent pas émettre de certificats valides pour tous les sites que vous visitez, vous verrez donc beaucoup d'avertissements de certificat chaque fois que vous accédez à un site HTTPS, si ils essaient de décrypter le trafic pour le regarder.
Cependant, si vous utilisez une machine fournie par l'entreprise, elle pourrait installer une nouvelle autorité de certification, puis l'utiliser pour créer des certificats SSL pour les sites que vous visitez, donc cela ne se présenterait pas comme un problème.
Avec le côté VPN, cela pourrait être plus complexe si le VPN n'utilise pas SSL, mais la même théorie s'applique. Si vous accédez à Internet à partir d'une machine appartenant à quelqu'un d'autre sur un réseau qu'ils contrôlent, ils peuvent probablement accéder à tout contenu que vous entrez.
Si vous cherchez à éviter ce genre de problème, j'utiliserais un appareil que vous possédez/contrôlez pour accéder à Internet, de cette façon, vous devriez être averti si une interception SSL se produit.
À droite, les administrateurs du réseau d'entreprise mettent en œuvre une attaque d'homme au milieu contre le client TLS avec leur propre autorité de certification afin qu'ils puissent voir ce qui quitte leur réseau. Ils auront probablement un appareil qui créera à la volée un certificat valide pour gmail.com lorsque vous visiterez gmail.com. La raison pour laquelle ils le font n'est pas de jouer au Dr Evil, c'est pour qu'ils puissent se prémunir contre le fait que les secrets commerciaux soient expulsés de leur bâtiment via leur connexion Internet. Sérieusement, ne faites pas vos opérations bancaires privées sur un ordinateur professionnel.
Si vous utilisez un produit logiciel qui n'utilise pas le magasin de certificats système (par exemple, une instance OpenVPN), alors, non, ils ne peuvent pas intercepter et décoder votre trafic car vous ne faites pas confiance à leur autorité de certification. Vous pourriez obtenir le même résultat en utilisant une application portable Firefox, par exemple. Et dans la plupart des navigateurs, vous pouvez vérifier les détails de votre connexion sécurisée et voir qui est l'AC, pour être sûr de savoir qui écoute ou non.
Le proxy peut bloquer https et autoriser uniquement http à partir du navigateur. Il peut ensuite lancer sa propre connexion https pour transmettre les demandes au serveur.
La plupart des utilisateurs ne le remarqueront pas.
HSTS est censé arrêter cela, mais il n'est pas largement utilisé.
La terminaison SSL ou les produits proxy SSL comme Bluecoat doivent être sur votre réseau et compte tenu du coût, des procédures d'installation impliquées et de la politique de sécurité normale que toute organisation aurait qui installe ces produits - les menaces d'un attaquant malveillant utilisant un produit de terminaison SSL commercial sont presque zéro. OTOH - un initié de confiance ayant accès au NOC (Network Operations Center) pourrait en fait surveiller le trafic terminé par SSL et divulguer des informations sensibles.
Il s'agit d'une préoccupation commune (justifiée ou non) pour les entreprises mettant en œuvre des systèmes DLP.
TOUTEFOIS, DIT TOUT CE QUI - il y a un autre vecteur d'attaque qui est commun dans l'espace bancaire à domicile qui ne nécessite pas de proxy réseau et qui est des attaques de ferroutage/shim dans le navigateur - puisque le DOM a accès au trafic de texte clair avant qu'il ne frappe le Pipe SSL - c'est un vecteur d'attaque pratique et est souvent installé via une extension de navigateur. Il existe un excellent article Stackexchange sur les shims - n shim (aka polyfill) peut-il être installé dans IE, FF ou Chrome à l'insu de l'utilisateur, et peut-il lire les mots de passe saisis par l'utilisateur sur une page de connexion?