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

Pour la partie technique de l'interception TLS, les enjeux sont surtout sécuritaires. Après tout, la mise en place de l'interception se fait car le TLS rendait les équipements de sécurité sur un mode de fonctionnement dégradé. C'est-à-dire un mode de fonctionnement ne permettant pas aux équipements de remplir leurs fonctions avec efficacité. Les différentes notions qui seront vues par la suite, sont celles rendues inopérantes par le TLS mais que l'interception TLS permet de rendre opérationnelles.

Depuis quelques années, les pare-feux nouvelle génération ont vu le jour. Ils permettent des analyses de flux plus poussées et embarquent maintenant des composants permettant de reconnaître les protocoles. Aussi, ces pare-feux ne se basent plus uniquement sur des informations de bas niveau (3 et 4 du modèle OSI), mais également de haut niveau en étant capables de reconnaître un flux HTTP par exemple. Ainsi, avec cette capacité d'analyse, ces équipements proposent de plus en plus d'outils de filtrage en fonction des applications. Notamment, ils sont souvent eux-mêmes utilisés comme proxy TLS pour faire de l'interception.

Comme dit précédemment, ces pare-feux nouvelle génération permettent de reconnaître une application utilisée dans un flux (HTTP, TLS, SSH, SMTP, etc...). Pour cela, ils se basent sur des RFC et pattern de données pour différencier les applications. Cette protection est plus efficace que le simple filtrage d'un ou plusieurs ports. En effet, les anciens pare-feux se limitaient uniquement aux réseaux et transports (TCP ou UDP) utilisés. Aussi, il était possible d'utiliser n'importe quel protocole à partir du moment où le port était bon. De plus, ces nouveaux équipements permettent également de garantir la fiabilité du protocole filtré. En effet, sachant reconnaître les applications, les pare-feux peuvent détecter des anomalies d'utilisation (mauvaises requêtes à un mauvais moment par exemple, tailles d'en-têtes anormales, etc...) et même appliquer des analyses IDS/IPS ¹ (exemple : détection d'injection de code dans du HTTP). Ce genre d'analyse est très précieux pour les flux allants et venants d'Internet. Comme il est impossible de maîtriser les différents tiers se situant sur Internet, l'analyse protocolaire permet de protéger fortement les utilisateurs d'un réseau contre les diverses attaques provenant d'Internet, voire de protéger les serveurs publiés sur Internet des nombreuses attaques.

Les analyses « classiques » vont regrouper toutes les analyses liées aux malwares² et les spams. Généralement, les postes clients sont équipés d'un antivirus local pour se protéger. Cette protection se

base souvent sur une analyse basée sur la signature ³, qui par nature permet de détecter rapidement des malwares connus. Le principal risque de ce genre d'analyse est la latence entre la création d'un nouveau malware et la notification de sa signature. Pour pallier cela, les analyses heuristiques⁴ sont nécessaires. Or, ce type d'analyse demande une certaine puissance de calcul que les postes bureautiques n'ont pas. A la place, les entreprises ont soit des équipements d'analyses dédiées (sandbox ⁵), soit des services hébergés par des prestataires de sécurité qui ont de fortes capacités d'analyses auxquelles sont envoyées les données à analyser.

La perte et la fuite de données sont une hantise pour toutes les entreprises. Les causes de ces pertes sont très nombreuses: fuite de données suite à une attaque interne ou externe, transmission de données bancaire suite à une campagne de phishing⁶, utilisation d'une plateforme d'échange non autorisée par l'entreprise, etc...

Contre ça, les techniques de prévention de pertes de données (Data Loss Prevention) ont vu le jour. Ces techniques utilisent l'analyse en profondeur des données pour détecter des patterns bien particuliers dans des contextes donnés. Aussi, si une personne essaye d'envoyer une donnée sensible à travers un moyen de communication considérée comme non sécurisée par l'entreprise, l'équipement en charge de la prévention pourra supprimer tout ou une partie du flux concerné.

En fonction de son utilisation, l'interception TLS est placée soit en mode proxy TLS, soit en mode reverse proxy TLS ⁷. Dans les deux cas, cela permet de scinder un flux entre deux tiers passant par l'équipement. Ce faisant, il est possible de limiter le taux d'exposition des clients et serveurs d'une entreprise à Internet. L'autre avantage d'un proxy est le cache pour les pages web, permettant de limiter le nombre de connexions vers Internet et donc l'économie de la bande passante qui est onéreuse.

Un inconvénient majeur du TLS et de son chiffrement est l'impossibilité de journaliser les informations des protocoles encapsulées dans le TLS. Même si la problématique majeure de la journalisation est liée aux aspects juridiques que nous verrons par la suite, le côté technique a également un fort besoin de ces journaux. Que ce soit pour résoudre des incidents ou auditer l'utilisation du système dans sa globalité ou partiellement, les logs sont une composante importante dans la vie d'un système informatique.

Les journaux sont la première source de données permettant d'assurer l'exploitation au quotidien d'un système. Sans trace, il est impossible de comprendre une anomalie passée, ni même de comprendre l'état actuel du système. En particulier, les métadonnées des protocoles sont une source d'information précieuse qui permet de définir le contexte dans lequel s'est déroulée la connexion (l'heure, la source, la destination, l'action, les paramètres, etc...). Ainsi, ces éléments sont très importants pour toutes actions d'investigations sur des anomalies rencontrées. Ils permettent de comprendre, voire de reproduire, les incidents afin de mettre en place des contre-mesures adéquates pour protéger la production de l'entreprise.

	HTTP	TLS	TLS intercepté
Temps de traitement global (en s)	132,552	171,716	772,082
Requêtes traitées par seconde	37,72	29,12	6,48
Requêtes échouées	0	0	99

Les journaux sont aussi très utiles à la détermination de la volumétrie d'un système informatique. Selon la configuration de la journalisation, celle-ci peut permettre d'évaluer le nombre de connexions (total ou dans une période donnée) d'un ou plusieurs protocoles. Ainsi que de déterminer la quantité de données échangées dans les protocoles (si la journalisation ressort bien ce type de données). Ces deux informations sont cruciales pour un système informatique car elles permettent de connaître l'évolution de son utilisation et anticiper un dépassement des limites imposées par le système.

Pour la partie technique, les risques de l'interception TLS vont se concentrer sur la limitation technique des équipements utilisés, mais aussi sur la modification d'utilisation du TLS entraînée par l'interception.

La principale limite à prendre en compte pour l'interception TLS est la ressource qu'elle va utiliser. Le TLS repose sur plusieurs algorithmes mathématiques utilisant de grands nombres, complexifiant ainsi les calculs. Par conséquent, l'utilisation du TLS est en soi consommatrice de ressources. En effet, l'équipement utilisé comme proxy TLS va établir deux sessions, là où les clients et serveurs n'en utiliseront qu'une seule. Le tableau tab. 5.1 p.33 et le graphique fig. 5.1 p.34 montrent un comparatif basé sur l'envoi de 5000 connexions HTTP, dont 30 sont envoyées simultanément, en clair, en TLS et en TLS intercepté⁸.

Avec ce comparatif, il est facile de voir que l'interception TLS a des impacts significatifs sur la gestion des flux. En effet, par rapport à un flux TLS classique, le fait d'intercepter demande plus de puissance de calcul, et avec la gestion parallèle des connexions, le nombre de requêtes pouvant être gérées chute brutalement. Autre point à prendre en compte : le taux d'échec de l'interception TLS. Comme il est possible le voir dans l'exemple, l'interception TLS échoue dans la transmission des requêtes. Ces anomalies proviennent surtout sur des erreurs d'échange dans l'établissement TLS.

Bien que l'impact directement visible repose sur le nombre de connexions simultanées pouvant être gérées, la problématique provient surtout des éléments physiques de l'équipement dédié à être proxy TLS. En effet, que l'équipement soit équipé de cryptoprocesseurs⁹ ou non, l'interception TLS peut entraîner une saturation du système de calcul. Or, si le système de calcul est saturé, alors les divers flux vont être mis en file d'attente jusqu'à leur traitement. Mais si le cryptoprocesseur n'est pas assez performant, alors la file d'attente ne cessera de s'agrandir jusqu'à ce que des comportements anormaux apparaissent (blocages de flux, flux non déchiffrés, etc...). Le problème étant plus grave si l'équipement ne fournit pas de cryptoprocesseur et utilise son processeur classique. Dans ce cas, c'est tout le système d'exploitation de l'équipement qui peut être en péril. Et puisque le proxy TLS doit être placé en coupure de réseaux entre les clients et les serveurs, sa saturation peut entraîner un arrêt complet du réseau sur lequel il se situe.

Outre les problèmes liés à la performance, l'interception TLS apporte de lui-même un lot de contrainte à prendre en compte. Si ces contraintes sont mal estimées avant le déploiement de cette technique, les impacts sur le système d'information peuvent être préjudiciables à l'organisme voulant la mettre en place.

Comme pour la plupart des équipements d'un système informatique, les éléments de sécurité ont généralement une durée de vie de 5 années. Or, le monde des chiffrements sécurisés évolue plus vite. En effet, de nouveaux algorithmes (notamment pour la génération de grands nombres premiers avec Diffie-Hellman ¹⁰) voient le jour et sont implémentés sur les serveurs web au détriment des plus anciens. La problématique pour un proxy TLS dans ce contexte d'évolution est d'être en capacité de suivre cette évolution. Si le proxy TLS n'est pas capable d'apprendre les nouveaux algorithmes, ou uniquement en étant mise à jour, cette contrainte devient sérieuse afin de limiter les temps de coupure.

Pour prendre un exemple, le site « moodle.com » 11 a récemment mis à jour sa configuration TLS. Depuis cette modification, ce site n'accepte les algorithmes Diffie-Hellman que s'ils utilisent une méthode appelée elliptic curve ¹². Chez un client, j'avais mis en place de l'interception TLS via une solution tierce, avant cette modification opérée par « moodle.com ». Or, cette solution ne sait pas gérer cette notion de courbe elliptique dans les algorithmes de chiffrement. Pour être mise à jour, la solution a besoin d'une montée de version majeure qui aura un impact significatif sur le système informatique. Sans cette montée de version, le client n'a d'autre choix que d'autoriser « moodle.com » sans le déchiffrer. Ainsi, le choix qui s'impose au client est le suivant :

Dans ce genre de cas, le choix est cornélien et peut poser une véritable problématique sur l'évolution future du système informatique. En effet, la décision sera prise en calculant l'impact économique prévisionnel dans les deux cas de figure, l'impact le plus bas sera le plus déterminant. Or, l'évaluation de l'impact peut être très compliquée à prendre en compte si la direction manque d'informations sur la multitude de facteurs à appréhender.

Un problème récurrent lié aux proxy TLS est leur « souplesse ». Souvent dans leurs configurations, les proxy TLS vont proposer un ou plusieurs paramétrages possibles pour l'interception TLS en fonction des cas de figure. Or, ce nombre de paramétrages reste toujours limité et lié à des critères de reconnaissance de flux précis. A cela s'ajoute souvent la difficulté de spécifier les algorithmes de chiffrement voulu. Il y aura souvent des notions de niveau cryptographique dans les équipements qui regrouperont des suites cryptographiques, mais il reste rare de pouvoir personnaliser ces niveaux.

Par conséquent, le choix de limiter ou non les suites cryptographiques demande une sérieuse réflexion en fonction des besoins. Soit, la décision est de n'accepter que des chiffrements robustes, dans quel cas une multitude de sites divers ne sera plus acceptée. Soit, les algorithmes plus faibles sont acceptés, ce qui augmente le risque qu'un individu malveillant puisse déchiffrer le flux.

Attention toutefois, autoriser des algorithmes de chiffrement moins robustes ne veut pas forcément dire que ces derniers présentent des failles importantes, mais au vu des techniques de cryptanalyses 13 actuelles, « moins » de temps est nécessaire pour déchiffrer un flux, mais cela reste impossible pour un simple poste de procéder à la cryptanalyse en un temps raisonnable 14.

Nous avons vu précédemment que l'interception TLS à un impact significatif sur la vitesse de traitement des requêtes. Une des causes est que lors de l'interception sortante, le proxy TLS, avant de créer un faux certificat pour le client, va procéder à des vérifications d'usage sur le certificat serveur. En effet, il va tester qui a signé le certificat, sa date de validité, si le nom du certificat correspond au domaine requêté, etc... Afin de minimiser le temps de traitement lié à la validation du certificat, certaines solutions proposent un cache de certificats TLS générés à la volée. Ainsi, le proxy TLS a, par le passé, procédé aux vérifications d'usages d'un certificat puis généré le faux pour le client, alors il garde ce dernier en mémoire pour un temps. Lorsqu'un client, le même ou un autre, vont vouloir accéder au site présentant le certificat en question, le proxy TLS ne procédera pas aux vérifications et présentera le certificat généré précédemment.

Cette fonctionnalité de cache permet de gagner un temps précieux, notamment si un nombre conséquent de requêtes sont à traiter simultanément, mais elle peut également être une source de risque important. Le proxy TLS va donc se reposer sur son cache qui garde généralement quelques jours. Durant cette période, le proxy TLS n'effectuera aucune vérification sur le certificat serveur. Or, si ce dernier a été corrompu récemment, alors il y a un vrai risque que la confidentialité des données soit remise en cause le temps que le cache soit purgé.

Lors de l'établissement d'une session TLS, le serveur peut demander au client une authentification via un certificat afin de s'assurer de l'identité du client. L'interception TLS pose un réel problème pour ce mode d'authentification. En effet, il est impossible de procéder à l'identification du client via un certificat.

Pour être plus précis, ce n'est pas le fait de transférer la demande du serveur et le certificat client qui pose problème, mais l'utilisation du certificat client par la suite. Pour rappel, le proxy TLS placé en coupure se fait passer à la fois pour un client et un serveur en fonction de son interlocuteur. Il établit donc deux sessions TLS avec le client et le serveur, et par conséquent, chaque échange qu'il effectue est signé afin d'assurer l'intégrité et l'identification du message. Or, dans le cas d'une authentification client par certificat, les deux protagonistes ne savent pas que leurs trafics sont interceptés. Donc, lorsque le client voudra échanger avec le serveur, ce dernier connaîtra le certificat du client, et voudra vérifier que tous les messages qu'il reçoit ont bien été signés avec le certificat du client. Ceci impossible, car le trafic étant intercepté, les messages seront signés avec le certificat du proxy TLS.

Pour ce genre de connexion, seule une liste blanche permettant d'outrepasser l'interception TLS est envisageable pour rendre les sites demandant une authentification accessible. Dans le cas contraire, le flux sera bloqué.

Évidemment, le but de l'interception TLS est d'avoir le trafic en clair pour y apporter des analyses diverses, mais cela reste un risque en soi. L'utilisation du TLS permet la confidentialité lors d'un échange où les données sont censées être sensibles, or, sur le proxy TLS, le trafic est momentanément stocké en clair. Par conséquent, si le proxy TLS est compromis (accès par un individu non autorisé), la confidentialité des flux est également compromise.

Dans le cas d'une interception de flux sortants, nous avons vu que le proxy TLS a besoin d'agir comme une autorité de certification interne pour générer de faux certificats à la volée. Pour cela, plusieurs solutions existent mais chacune apporte des risques.

Pour la mise en place de l'interception TLS, il faut réfléchir au mode de déploiement du certificat de l'autorité de certification interne auprès des divers clients internes. La principale difficulté réside souvent dans hétérogénéité des systèmes d'exploitation et navigateurs utilisés. Pour rappel, plusieurs méthodes ont été évoquées à la sous-section Le placement du proxy TLS p.25. Même si plusieurs méthodes de déploiement existent, aucune ne permet de prendre en compte tous les cas de figure. Notamment à cause du nombre considérable de navigateurs internet qui existent, et qui utilisent leur propre magasin de certificats. Il faudra donc prévoir comment déployer le certificat de l'autorité de certification sur tous les navigateurs utilisés au sein du système informatique.

Dans tous les cas, le principal risque restera la compromission du certificat et notamment de la clef privée qui lui correspond. Si cette dernière tombe entre de mauvaises mains, alors la confidentialité des flux interceptés n'existera plus. Mais aussi, cette compromission peut permettre à une personne compétente de créer des certificats de confiance auprès des utilisateurs faisant confiance à l'autorité de certification interne. Si une telle situation arrive, la priorité pour le système informatique sera de révoquer le certificat de l'autorité de certification interne au plus vite. De ce fait, dans le cas d'une utilisation d'une PKI interne, il est très important de dédier une sous-autorité de certification pour l'interception TLS afin de limiter l'impact d'une révocation du certificat de l'autorité utilisée. En effet, si un certificat d'une autorité ou sous-autorité est révoqué dans une PKI, alors la totalité des certificats générés par cette autorité ou sous-autorité seront invalides car l'autorité de certification intermédiaire ne sera plus de confiance. Ce risque peut-être très critique dans les architectures où le déploiement du certificat de l'autorité de certification doit se faire manuellement, cela veut dire que pour la révocation auprès des clients, elle devra également être également manuelle.

Dernier point concernant l'interception des flux sortants : il est fortement déconseillé d'utiliser les certificats d'autorité de certifications embarqués dans les solutions de proxy TLS. La raison évidente est d'éviter d'utiliser une paire de clefs connue par d'autres entités utilisant cette même solution. Par ailleurs, rien n'affirme comme n'infirme que l'éditeur de la solution n'a pas gardé une copie des clefs sur les équipements lors de leur production avant vente.

Pour l'interception entrante, le risque est tout autre. Le reverse proxy doit connaître toutes les paires de clefs dont il sera en coupure des serveurs internes. Par conséquent, il sera également concentrateur de certificats et clefs privées prévues initialement pour authentifier les serveurs hébergés en interne. Or cette fois-ci, les certificats sont bel et bien valides et reconnus publiquement. Par conséquent, la compromission du reverse proxy TLS va permettre aux personnes mal intentionnées de se faire passer pour les serveurs légitimes. La réplique directe devrait être de révoquer les certificats compromis, hélas, les temps de mise à jour sur Internet sont longs et beaucoup d'utilisateurs peuvent se faire avoir par des usurpateurs.

Même si l'interception TLS est tolérée dans un cadre précis que nous verrons par la suite, il ne fait pas le bonheur des éditeurs de navigateurs web, qui eux, veulent assurer la sécurisation des échanges, et notifier tout comportement suspect. Or, l'interception TLS agit comme une attaque dite Man In The Middle¹⁵ connue notamment pour usurper une identité sur un réseau. Ce genre de comportement fait partie des comportements suspects que les navigateurs web essayent de détecter. Dans le cas du TLS, les éditeurs redoublent d'efforts pour détecter les faux certificats. Ce qui est très bien pour les

utilisateurs, beaucoup moins pour les structures ayant besoin de l'interception TLS pour garantir un niveau de sécurité optimal de leur système.

La principale technique utilisée pour détecter les faux certificats est le HPKP ¹⁶ (HTTP Public Key Pinning). C'est une technique se basant sur la confiance au premier accès. C'est-à-dire que si le client et le serveur utilisent cette fonctionnalité, alors à la première connexion au serveur, celui-ci va renvoyer une liste des clefs publiques lui appartenant. Si lors de nouvelles connexions, la clef publique reçue n'est pas présente dans la liste de la première connexion, alors le navigateur coupe la connexion. Au bout d'une certaine période (envoyée par le serveur à la première connexion), la liste est purgée et la prochaine connexion sera autorisée pour récupérer la liste.

Il existe également d'autres techniques, ne provenant pas de RFC, qui voient également le jour comme CheckMyHTTP¹⁷ qui se base sur un tiers de vérification. C'est à dire que lorsque le client récupère un certificat en visitant un site, le client va envoyer une requête à un serveur de confiance se situant dans un autre réseau pour que celui-ci requête le certificat du site en question. Une comparaison entre le certificat reçu par le client et celui reçu par le serveur de confiance va permettre de déterminer si une attaque MITM (Man In The Middle) est en cours ou non.

La démocratisation de ces moyens de détection rend l'application de l'interception TLS très délicate. En effet, ce sont des mécanismes de détection que les navigateurs web proposent et donc ils nécessitent des paramétrages particuliers afin de les outrepasser. Selon la taille, hétérogénéité d'une structure et des droits accordés aux utilisateurs, il peut être très compliqué de trouver un processus permettant la configuration massive des postes clients. A l'instar des sites proposant une authentification des clients par certificat, il faudra prendre la réflexion du comportement des postes vis à vis de ces protections. Les sites doivent-ils faire partie d'une liste blanche outrepassant l'interception TLS au risque d'exposer le système informatique à des attaques? Ou alors, les sites doivent-ils rester bloquer? Ou encore, faut-il prévoir une configuration de tout ou une partie des postes du parc pour que les sites en question deviennent accessibles même avec l'interception TLS? Si ces questions sont simples à poser, elles restent difficiles à répondre en fonction du contexte dans lequel elles sont présentées.

Les postes clients ne sont pas les seuls à présenter des protections contre les attaques MITM. Les sites sécurisés trouvent des astuces pour détecter ces comportements et protéger leurs clients. C'est notamment le cas des sites bancaires et du gouvernement qui arrive à détecter les attaques MITM. Chaque site voulant détecter une attaque MITM procède à sa manière. Par conséquent, il n'est pas possible d'énumérer toutes les techniques existantes, ni même de les expliquer en détail car une grande partie de la détection se déroule en background des systèmes informatiques. Néanmoins, cet article va citer deux méthodes pour montrer ce qui peut être utilisé en matière de détection pour les serveurs.

Dans un article appelé The Security Impact of HTTPS Interception¹⁸, les auteurs proposent une méthode de détection d'interception TLS en se basant sur des analyses heuristiques portant sur le comportement des navigateurs connus lors de l'établissement d'une session TLS. Pour faire simple, ils ont découvert que chaque navigateur a une manière d'établir une session TLS (ordre des suites cryptographiques, extensions proposées, etc...). Si lors de l'établissement de la connexion TLS, le serveur détecte un comportement ne faisant pas partie de ceux connus en fonction du navigateur annoncé via l'en-tête User-Agent, alors le serveur considérera que la connexion est interceptée.

A l'instar des protections proposées par les clients, les serveurs peuvent aussi utiliser un tiers de confiance pour détecter une interception. Le projet open-source snuck.me¹⁹ permet au client d'avoir un comportement similaire proposé par CheckMyHTTP vu précédemment. Sauf que cette fois, ce sont les pages web du site qui embarquent du code JavaScript qui va permettre d'effectuer la vérification. Aussi, il n'est pas possible de configurer le poste client pour outre passer la vérification, puisque c'est le site lui-même qui effectue la vérification depuis le poste client.

Contrairement aux protections des postes clients, les protections des serveurs contre les attaques MITM sont très pénibles à prendre en compte pour un système informatique. Puisque les vérifications sont faites, soit par les pages web reçues, soit par les serveurs distants. Il n'est pas possible d'agir

Enjeux	Risques
L'analyse protocolaire (reconnaissance des applica-Peut tions)	poser des problèmes de performances réseaux
La détection des malwares dans les flux	Évolution rapide des suites cryptographiques
La détection de la prévention de perte/fuite de don- nées	Le manque de modularité des proxy TLS dans la gestion des suites cryptographique
Avoir une coupure entre client et serveur comme pour un proxy	Le cache TLS peut autoriser des certificats non valides sur une courte période
Avoir la même politique de journalisation des pro- tocoles comme s'ils étaient en clairs	Authentification des clients TLS par certificats im-possibles
	Le proxy TLS stocke les flux en clair le temps d'appliquer les analyses
	La gestion (création, déploiement, révocation) des certificats peut être compliquée en fonction du contexte
	Protections des clients qui peuvent être compliquées à contourner
	Protections des serveurs qui ne sont pas outrepas-sables

directement pour outre passer la vérification. La plupart du temps, la question à se poser concernant ces sites sont : doit-on les laisser inaccessibles? Doit-on les mettre en liste blanche?

Afin d'y voir plus clair dans les enjeux et les risques liés aux éléments techniques de l'interception TLS, le tableau tab. 5.2 p.38 va reprendre les divers points vus précédemment. Même si à première vue, il existe plus de risques que d'enjeux à mettre en place l'interception TLS sur un plan technique, il ne faut pas se fier au seul nombre de points enjeux/risques. En effet, la pondération de ces points est primordiale car variera fortement en fonction du contexte. Par exemple, le risque lié aux problèmes de performances réseau n'est valable que dans le cas où un fort trafic est analysé.

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

Chapitre 5