Un client de bureau A se connecte au site Web W dans une connexion https
A --> W D'une manière ou d'une autre entre A et W, il y a est un proxy G.
A --> G --> W HTTPS est basé sur la 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 un é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 :
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 car le serveur a la clé privée correspondante .
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 la 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 certificat réel 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. Cependant, cela détruira la signature des autorités de certification . Le navigateur vous avertira du certificat invalide.
Si l ' administrateur de votre ordinateur coopère , il est possible pour un serveur proxy de détecter les connexions https. Ceci est utilisé dans certaines entreprises afin de rechercher des virus et d'appliquer les directives d'utilisation acceptable.
Une autorité de certification locale est installée et l'administrateur informe votre navigateur que cela CA est digne de confiance . Le serveur proxy utilise cette autorité de certification pour signer ses faux certificats.
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 n'importe quelle ressource standard sur SSL / TLS, par exemple,
PS Le certificat est une donnée publique. 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 c'est inoffensif.)
Du blog technique de Philipp C. Heckel avec quelques légères modifications:
Il est possible d'attaquer le trafic HTTP non chiffré sans avoir à gérer les certificats X.509 et les autorités de certification (CA), les connexions HTTPS cryptées SSL chiffrent chaque demande et réponse entre le client et le serveur de bout en bout. Et comme 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: Premièrement, 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, également: 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 la connexion, le serveur proxy peut agir comme une autorité de certification, mais pas très digne de confiance: à la place d'émettre des certificats à des personnes ou à des organisations réelles, le proxy génère dynamiquement des certificats pour n'importe quel 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 vraies (autorité de certification 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 demande / réponse 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 en mesure d'intercepter les paquets IP - ce qui signifie qu'il doit être quelque part le long du chemin du chemin du paquet. Le moyen le plus simple d'y parvenir consiste à remplacer la passerelle par défaut de l'appareil client 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!) au proxy CA, c'est-à-dire que le fichier de clé CA doit être ajouté au trust store du client.
Si vous souhaitez renifler de manière transparente les sockets SSL simples, vous pouvez essayer
SSLsplit, un proxy transparent TLS / SSL 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 (CA) non autorisée ou de variantes des attaques SSL man-in-the-middle de l'expert en sécurité Moxie Marlinspike. Pourquoi vous donner tous ces problèmes lorsque vous pouvez simplement acheter un proxy d'interception SSL, tel que ProxySG de Blue Coat Systems ou leur appliance SSL Netronome récemment acquise pour faire le travail à votre place?
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 offrant l'interception SSL et le break in a box. Jusqu'à récemment, par exemple, Microsoft vous vendait un programme, Forefront Threat Management Gateway 2010, qui pourrait également faire le travail à votre place. Avec un programme ou un appareil proxy d'interception SSL en place, voici ce qui se passe réellement:
Si votre entreprise a correctement configuré le proxy, vous ne saurez pas que quoi que ce soit est désactivé, car ils auront fait en sorte que le certificat SSL interne du proxy soit enregistré sur votre machine en tant que 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, 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, donc vous verriez beaucoup d'avertissements de certificat à chaque fois vous accédez à un site HTTPS, s’ils essaient de décrypter le trafic pour le consulter.
Cependant, si vous utilisez une machine fournie par la société, ils peuvent installer une nouvelle autorité de certification, puis l'utiliser pour créer des certificats SSL pour les sites que vous visitez, afin que cela ne se présente pas comme un problème.
Avec le côté VPN des choses, 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 en cas d'interception SSL.
À droite, les administrateurs du réseau d'entreprise implémentent une attaque d'intermédiaire contre le client TLS avec leur propre autorité de certification afin qu'ils puissent voir ce qui sort de leur réseau. Ils disposeront probablement d'un appareil qui créera à la volée un certificat valide pour gmail.com lorsque vous visiterez gmail.com. La raison pour laquelle ils font cela n'est pas de jouer au Dr Evil, c'est pour qu'ils puissent se prémunir contre le transfert de secrets commerciaux hors de leur immeuble via leur connexion Internet. Sérieusement, ne faites pas vos opérations bancaires privées sur un ordinateur de travail.
Si vous utilisez un 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écodez votre trafic parce que vous ne faites pas confiance à leur autorité de certification. Vous pouvez 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'autorité de certification, pour être sûr qui écoute ou non.
Le proxy peut bloquer https et autoriser uniquement http à partir du navigateur. Ensuite, il peut initier sa propre connexion https pour transmettre les requêtes 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 de toute organisation qui installe ces produits - les menaces d'un attaquant malveillant utilisant un SSL commercial le produit de terminaison est presque nul. OTOH - un initié de confiance ayant accès au NOC (centre d'opérations réseau) 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 AYANT DIT TOUT CELA - il existe un autre vecteur d'attaque qui est courant dans l'espace bancaire à domicile qui ne nécessite pas de proxy réseau et qui est des attaques piggback / shim dans le navigateur - puisque le DOM y a accès pour effacer le trafic de texte avant qu'il n'atteigne le canal 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 - Un shim (alias polyfill) peut-il être installé dans IE, FF ou Chrome sans que l'utilisateur en soit informé, et peut-il lire les mots de passe saisis par l'utilisateur sur une page de connexion?