L'interception SSL/TLS : le fonctionnement, entre enjeux et risques, les bonnes pratiques

Chapitre 3

L'interception TLS

L'interception TLS est une technique basée sur Man In The Middle (l'homme du milieu) qui consiste à interposer un proxy TLS entre un client et un serveur, puis usurper l'identité de chacun auprès de l'autre comme le montre le schéma fig. 3.1 p.23.

Ce schéma très grossier représente parfaitement l'idée derrière cette technique. Détruire l'idée d'un canal de bout en bout afin de créer deux canaux, un du client au proxy TLS, l'autre du proxy TLS au serveur. Ainsi, il n'y a pas de déchiffrement mais juste deux connexions TLS bien distinctes permettant au proxy TLS de voir le contenu en clair. Bien sûr, cette technique est loin d'être anodine et demande une grande vigilance quant à son exécution. Pour rappel, le TLS se base sur l'authentification de chaque partie pour s'assurer de l'identité de chaque partie. En outre, c'est surtout le client qui a besoin de connaître l'identité du serveur. Or, avec cette technique d'usurpation, comment faire pour outrepasser le système d'authentification? En effet, l'identité du serveur est censée être approuvée et contrôlée par une autorité de certification indépendante ce qui permet d'éviter toutes formes d'usurpations à partir des éléments publics. Pour répondre à cette question, il est nécessaire de voir en détail les étapes permettant de mettre en place cette technique.

L'interception TLS n'est pas une technique normalisée, notamment parce qu'elle met à mal la sécurité du TLS définie dans la RFC 5246. Par conséquent, tous les équipements et logiciels permettant de mettre en place cette technique ont leur propre implémentation. Cet article va présenter la façon générale et les détails qui doivent être pris en compte pour réussir cette technique. Pour cela, il est important de comprendre qu'il existe deux types d'interception TLS : l'interception sortante et entrante. Pour mieux saisir ces notions d'entrant et sortant, le schéma fig. 3.2 p.24 les illustre.

L'interception sortante portera donc sur les flux initiés depuis l'environnement géré (ex : Petitjean Corp) vers d'autres environnements (ex : Internet). A l'inverse, l'interception entrante se basera sur les connexions venant depuis d'autres environnements (ex : Internet) que celui qui est géré (ex : Petitjean Corp).

FIGURE 3.1 - Man In The Middle

Edouard Petitjean M2 MIAGE SIID 24

L'interception TLS - L'interception TLS sortante

FIGURE 3.2 - Différence entre connexion entrante et sortante

3.1 L'interception TLS sortante

L'interception TLS sortante est la pratique la plus courante et la plus compliquée à mettre en place. Elle va permettre d'intercepter toutes les connexions dont les sources sont souvent les utilisateurs d'une entreprise vers des sites distants. Pour cela, les utilisateurs passeront, de façon transparente', par un proxy TLS qui interceptera les requêtes, puis ce dernier va initialiser lui-même les connexions vers les diverses destinations. Néanmoins, cette pratique à une limite : la rupture de la confiance. En effet, il ne faut pas oublier que le client va vérifier l'identité du serveur de son côté. Or, dans cette architecture basée sur l'interception, le client va établir une session TLS avec le proxy TLS à son insu, donc le certificat que va renvoyer le proxy TLS ne correspondra pas, tant sur son nom que sur l'AC, à ce qu'aura demandé le client.

Pour pallier cette limitation, le proxy TLS devra avoir la capacité de générer des certificats à la volée et considérés comme valides par le client. Comment? Le proxy TLS devra utiliser une autorité de certification reconnue par les clients. Le schéma fig. 3.3 p.25 montre un exemple.

1. Chris veut établir une connexion avec « www.site-sécurisé.com ». Pour cela, il envoie une requête Client Hello à « www.site-sécurisé.com »

2. Le proxy TLS est positionné dans l'architecture réseau de telle sorte qu'il soit sur le chemin allant vers « www.site-sécurisé.com ». Lorsqu'il voit une requête TLS, il va l'intercepter et mettre le client en attente. Puis il va établir une connexion avec « www.site-sécurisé.com », soit en reprenant exactement les paramètres que le client a indiqués dans son Client Hello, soit en modifiant certaines valeurs pour accentuer les paramètres de sécurité par exemple.

3. Le serveur « www.site-sécurisé.com » établit une connexion sans problème particulier. Pour lui, le proxy TLS est un client comme un autre. Par conséquent, le serveur renvoie les paramètres qu'il aura choisis ainsi que son certificat et sa chaîne de certificat. Dans le schéma, le certificat a été

1. Pour que cette technique fonctionne, le client ne doit pas repérer une quelconque interception du flux. Puisque le TLS a été pensé pour justement éviter les interceptions.

Edouard Petitjean M2 MIAGE SIID 25

L'interception TLS - L'interception TLS sortante

FIGURE 3.3 - Interception TLS sortante

créé pour répondre au nom « www.site-sécurisé.com » et il a été signé par « AC Intermédiaire » (une AC publique quelconque mais dont la racine est reconnue par les navigateurs).

4. Après que le proxy TLS ait reçu le certificat du serveur et sa chaîne, il procède aux vérifications d'usage et décide si la connexion peut-être établie. Une fois la session TLS établie, elle reste en attente jusqu'à ce que le vrai client envoie des données. Par la suite, le proxy TLS va reprendre les données du certificat du serveur pour en recréer un autre temporaire et qui sera signé par son AC interne à l'entreprise « proxytls.local » et qui est connu par les navigateurs de l'entreprise. Puis ce nouveau certificat sera utilisé par le proxy TLS pour usurper l'identité de « www.site-sécurisé.com » auprès du client.

Le faux certificat généré par le proxy TLS aura donc les caractéristiques suivantes :

-- Sujet : www.site-sécurisé.com -- Emetteur : proxytls.local

Par conséquent, lorsque le client voudra vérifier le certificat qui lui est présenté, il pourra constater que le sujet correspond au domaine et que l'AC qui a signé le certificat est reconnue par le client. Il établira donc une connexion TLS sécurisée avec le proxy TLS en pensant être directement connecté à « www.site-sécurisé.com »

3.1.1 Le placement du proxy TLS

Le proxy TLS doit avoir une position particulière sur le réseau afin de mener sa tâche. Même s'il est couramment appelé Proxy TLS, il est assez rare qu'il représente un équipement dédié. En effet, c'est souvent un proxy ou pare-feu qui porte ce rôle. Une préférence d'ailleurs pour les pare-feux qui font maintenant de l'analyse protocolaire et donc portent des analyses d'inspections. Le rôle d'interception TLS est tout indiqué pur ces équipements qui mutualisent les analyses de haut niveau.

L'emplacement du proxy TLS dans l'architecture du réseau est également une notion importante. Il doit être « transparent » pour le client, donc il doit être un noeud obligatoire du chemin réseau entre le(s) client(s) et les sites distants. Les proxy TLS seront donc très souvent proches des accès Internet, voir sont les équipements frontaliers entre le réseau d'entreprise et Internet. Cette transparence n'est pas anodine. Le TLS a été conçu pour créer des canaux sécurisés pour la confidentialité et se repose sur des systèmes d'authentification (certificat X.509) afin d'éviter les usurpations d'identités. Donc, il n'est pas prévu pour les clients d'avoir une fonctionnalité permettant de passer par un serveur mandataire TLS qui ferait de l'interception comme pour des services proxy tels que HTTP, FTP, IMAP, etc...

3.1.2 Une autorité de certification interne

Pour recréer des certificats et les signer à la volée, le proxy TLS devra contenir une autorité de certification qui permettra de procéder à ces opérations. Or cette autorité ne se sera pas reconnue par défaut par les clients. Seules les autorités racines publiques le sont, et aucune d'entre elles n'accepterait de délivrer une autorité de certification intermédiaire à un tiers quelconque pour deux raisons.

La première est que ça voudrait dire que l'autorité de certification publique délègue le droit à un tiers de créer et signer des certificats à son nom. Ce genre de délégation peut-être dangereuse et engagerait la responsabilité de l'autorité. La deuxième raison est que la technique d'interception TLS va en l'encontre de ce que protège les autorités de certification : l'identité derrière les certificats. Le

Edouard Petitjean M2 MIAGE SIID 26

L'interception TLS - L'interception TLS entrante

FIGURE 3.4 - Interception TLS Entrante

risque pour une autorité de certification d'outrepasser ce principe est très important. L'histoire de MCS Holding qui avait reçu une délégation de la part de la CNNIC², avait outrepassé ses droits en créant un faux certificat Google pour tester une technique d'interception TLS. Google ayant repéré ce certificat avait décidé de révoquer dans son navigateur Chrome l'autorité de certification racine provenant de la CNNIC. Conséquence, les utilisateurs utilisant Chrome (environ 45% de part de marché au moment des faits ³) pouvaient accéder à ces sites mais une erreur de certificat apparaissait.

Puisqu'il n'est pas possible de passer par une autorité publique pour obtenir une AC permettant de faire de l'interception TLS, il faut utiliser une AC interne au système informatique. Pour cela, plusieurs solutions sont possibles.

-- PKI interne: elle est souvent utilisée dans les grandes organisations qui utilisent des certificats pour authentifier leurs équipements en interne. Avec une PKI interne, il est possible d'exporter les clefs (publique et privée) pour les importer dans le proxy TLS. Une bonne pratique serait de créer une sous-autorité dédiée au proxy TLS.

-- Le déploiement par GPO : les structures se basant sur Active Directory ont la possibilité de déployer massivement des certificats sur les postes. Pour cela, le proxy TLS hébergera une autorité de certification auto signée puis son certificat sera déployé par une GPO 4.

-- Autres déploiements: Dans les autres architectures utilisant des navigateurs comme Firefox, d'autres moyens de déploiement doivent être pensés. C'est souvent cette problématique qui freine les entreprises voulant mettre en place cette technique. Il existe cependant plusieurs techniques nécessitant ou non une manipulation des utilisateurs. Par exemple pour Firefox, celui-ci utilise son propre magasin de certificat, néanmoins, la version ESR et les dernières versions basiques ont une fonction permettant d'utiliser le magasin Windows. Autre exemple, il est possible de publier le certificat de l'autorité sur une page Web, ajoutable par action manuelle de l'utilisateur, ou encore via du code JavaScript dans un fichier de configuration du navigateur. D'autres techniques existent en fonction du contexte. Le plus compliqué étant de trouver la meilleure méthode de déploiement en fonction des contraintes propres aux réseaux de l'entreprise.

3.2 L'interception TLS entrante

Cette fois, le serveur accessible par les clients se situe en interne du système géré alors que les clients proviennent de n'importe où. Cette technique est plus simple à mettre en place, et pour cause, l'identité que le proxy TLS doit usurper est gérée par le système d'information. Ainsi il n'y aura pas de création de certificats à la volée. Mais un doublon de clefs (publiques et privées) sera présent sur le réseau. En effet, le proxy TLS portera les deux clefs du serveur interne qu'il présentera aux différents clients. Le schéma fig. 3.4 p.26 montre un exemple de cette interception.

2. China Internet Network Information Center, autorité de certification chinoise

3. Mars 2015 : https://www.w3counter.com/globalstats.php?year=2015&month=3 et http://gs.statcounter.com/ browser-market-share/all/worldwide/2015

4. Les GPO (Group Policy Object) sont des ensembles de paramétrages de postes Windows, récupérés depuis un serveur, qui sont appliqués à divers moments selon des critères précis.

Edouard Petitjean M2 MIAGE SIID 27

L'interception TLS - L'interception TLS entrante

1. Bob veut établir une connexion sécurisée avec « www.edouard-petitjean.com ». Il envoie une requête Client Hello à « www.edouard-petitjean.com »

2. Le proxy TLS intercepte la requête du client. Il récupère les différents paramètres que le client a initié et établi une connexion TLS avec le serveur interne.

3. Le proxy répond au client avec un Server Hello et envoie le certificat du serveur. La connexion TLS s'établit normalement. Puisque le certificat est valide (il correspond au domaine requêté et est signé par une AC publique), aucune erreur n'est détectée par les clients.

3.2.1 Le placement du proxy TLS

Comme pour la technique précédente, le proxy TLS devra se placer en coupure réseau entre les clients et le serveur. Sauf que cette fois, sa position sur le réseau peut-être à plusieurs endroits selon l'architecture en place. Il peut être proche de l'accès externe tout comme proche du serveur. Bien que la seconde option est préférable de par la présence des clefs privées des serveurs qu'il héberge et la possibilité d'ajouter des couches de sécurité réseau entre le client et le serveur.

3.2.2 Hébergement des clefs privées

Cette technique ne va pas se baser sur une AC interne qui va régénérer des certificats. A la place, le proxy TLS va stocker toutes les paires de clefs des serveurs dont il devra usurper l'identité. Ainsi, comme le proxy TLS va intercepter les requêtes des clients, il pourra présenter sans problème le certificat concerné et déchiffrer le trafic grâce à la clef privée. La « simplicité » de cette technique tient au fait que le système informatique gère le serveur ainsi que le certificat et la clef privée associée. Il est donc simple d'importer cette paire de clefs à un proxy TLS qui répondra favorablement aux requêtes des clients.

Deuxième partie

Edouard Petitjean M2 MIAGE SIID 28

Des Enjeux et Des Risques

Edouard Petitjean M2 MIAGE SIID 29