Comment est-il possible de faire TLS via proxy sans que personne ne s'en aperçoive?
Mon lieu de travail utilise un proxy pour se connecter à Internet, même pour les sites https.
J'ai cru comprendre que pour que cela fonctionne, le proxy serait considéré comme un MITM et le certificat présenté proviendrait du proxy.
Cette racine de ce certificat devrait être approuvée, ce qui serait facile à réaliser via une stratégie de groupe dans un environnement d'entreprise.
Cependant, ce n'est pas ce que je vois.
Je vois les véritables chaînes de certificats sur le site Web cible, mais wirehark montre que je n'ai jamais touché que mon proxy.
Ce qui donne?
Depuis la version 1.1, HTTP prend en charge une méthode spéciale, CONNECT. Cela configure le tunnel TLS via le proxy, même si votre ordinateur ne se connecte directement qu'au proxy. HTTPS sait comment tunneler la prise de contact TLS même via le proxy.
Voir Wikipedia :
La méthode CONNECT convertit la connexion de demande en un tunnel TCP/IP transparent, généralement pour faciliter la communication cryptée SSL (HTTPS) via un proxy HTTP non crypté.
Une variante du tunneling HTTP derrière un serveur proxy HTTP consiste à utiliser la méthode HTTP "CONNECT".
Dans ce mécanisme, le client demande à un serveur proxy HTTP de transmettre la connexion TCP à la destination souhaitée. Le serveur procède ensuite à l'établissement de la connexion au nom du client. Une fois la connexion a été établie par le serveur, le serveur proxy continue de proxy le flux TCP vers et depuis le client. Notez que seule la demande de connexion initiale est HTTP - après cela, le serveur se contente de proxy la connexion établie TCP.
Ce mécanisme permet à un client derrière un proxy HTTP d'accéder à des sites Web à l'aide de SSL (c'est-à-dire HTTPS).
Mais notez cette mise en garde:
Tous les serveurs proxy HTTP ne prennent pas en charge cette fonctionnalité, et même ceux qui le font, peuvent limiter le comportement (par exemple, autoriser uniquement les connexions au port HTTPS par défaut 443 ou bloquer le trafic qui ne semble pas être SSL).
Normalement, lorsque HTTPS est effectué via un proxy, cela se fait avec le mécanisme CONNECT : le client parle au proxy et lui demande de fournir un tunnel bidirectionnel pour octets avec le système cible. Dans ce cas, le certificat que le client voit provient vraiment du serveur, pas du proxy. Dans cette situation, le proxy est conservé à l'extérieur de la session SSL/TLS - il peut voir que certains SSL/TLS ont lieu, mais il n'a pas accès aux clés de cryptage.
Certaines organisations implémentent un Man-in-the-Middle complet en générant à la volée un faux certificat pour le serveur cible. Ils le font précisément pour que le proxy puisse voir les données en texte clair et les analyser pour se conformer à la politique de l'organisation (par exemple, l'analyse antivirus automatique). Cela ne peut fonctionner que si le client (votre navigateur) accepte le faux certificat comme authentique, ce qui nécessite à son tour qu'une autorité de certification racine contrôlée par l'organisation soit poussée sur la machine cliente (et dans un monde Windows/Active Directory, un GPO peut le faire).
À propos de tous les principaux fournisseurs de pare-feu/proxy, ce mécanisme est proposé en option.
Toutes les organisations ne déploient pas un tel système MitM, pour plusieurs raisons, notamment:
MitM automatique peut être coûteux. L'appliance proxy peut devoir être puissante en termes de calcul s'il y a beaucoup d'utilisateurs; et la licence du produit peut être élevée.
MitM rompt l'authentification client basée sur les certificats.
Faire un MitM n'a de sens que si vous inspectez réellement les données, ce qui augmente à nouveau les coûts de calcul.
La poussée automatique d'une autorité de certification racine ne fonctionne pas avec BYOD .
En règle générale, les utilisateurs n'aiment pas vraiment ce MitM.