Aujourd’hui, pour protéger notre trafic internet, nous exploitons différents protocoles de chiffrement conçus pour ajouter une ou plusieurs fonctions de sécurité (confidentialité, intégrité, authenticité, imputabilité) sur les protocoles qui n’en possèdent pas nativement. L’un des plus utilisés est TLS (Transport Layer Security) développé par l’IETF, qui est l’évolution de SSL (Secure Socket Layer) développé par Netscape. À titre d’exemple, TLS nous permet d’effectuer nos achats sur internet au moyen du flux WEB chiffré HTTPS (couche TLS pour HTTP).
par Raphaël Pion & Hugo Meziani
Laboratoire (C+V)O , Axe Confiance Numérique et Sécurité/Laboratoire de cryptologie et virologie opérationnelles (ESIEA)
1 Fonctionnement du Flux WEB chiffré
Lorsqu’un client consulte une page internet sécurisée, le serveur qui héberge ce site présente en premier lieu son identité. Pour cela, il fournit au client (votre navigateur WEB) un certificat électronique qui l’identifie de manière unique. Comment le client peut-il faire confiance à ce certificat pour authentifier le serveur ?
Au même titre qu’un notaire assure l’authenticité d’actes administratifs, il existe des Autorités de Certification (AC) pour les transactions numériques. Les navigateurs ont connaissance de ces AC à travers leurs certificats stockés dans des magasins qu’ils gèrent (cas de Firefox) ou gérés par le système d’exploitation (cas de Chrome et I.E. sous Windows).
Quand ces navigateurs se connectent à un serveur WEB sécurisé, il reçoivent le certificat d’identité du serveur. Ils vérifient que ce dernier est bien signé par une autorité présente dans leur magasin.
Deux cas d’usage peuvent apparaître :
Le premier cas : Le certificat présenté est authentifié.
Figure 1. Connexion avec un certificat signé.
Ce cadenas indique que le certificat du site consulté est signé (donc reconnu) par une autorité de la liste des AC. Le navigateur initie la connexion chiffrée avec le serveur.
Le deuxième cas : le certificat présenté n’est pas signé par une autorité reconnue (certificat non authentifié).
Figure 2. Mise en garde sur un certificat non signé
Dans ce cas, le navigateur demande à l’utilisateur de confirmer (en comprenant les risques) avant de lancer la connexion chiffrée. Le risque est qu’une personne ayant intercepté le flux ait présenté son propre certificat (reconnu ou non). Elle est alors en capacité de déchiffrer le contenu de la communication. On parle d’une attaque de type « homme du milieu » (Man-in-the-Middle ou MitM).
2 Interception du flux WEB chiffré
Dans une attaque de type « MitM », le but de l’attaquant est de récupérer le trafic de sa victime. Pour cela, il peut en exploiter deux techniques de détournement de flux (cf. Figure 3 et 4). Une fois le trafic récupéré, il peut directement lire les protocoles non chiffrés (FTP, HTTP, VOIP, etc.). Pour les flux chiffrés, l’attaquant doit fabriquer un « faux » certificat pour le présenter à sa victime qui constatera une alerte (cf. figure 2) dès qu’elle se dirigera vers un site en HTTPS. Comme les certificats comportent des champs spécifiques à chaque serveur (nom de domaine, date, etc.), l’attaquant doit être capable de les générer dynamiquement au rythme de la navigation de sa victime. Des outils comme « sslsplit » permettent d’automatiser cette tâche.
Figure 3. Détournement de flux en modifiant les cache ARP1.
Figure 4. Détournement de flux en intercalant un HUB sur le réseau.
En entreprise, cette pratique peut être mise en place via un proxy (figure 5). En France, cette surveillance de connexion chiffrée doit être explicitée dans la charte informatique signée par l’employé.
Figure 5. Exemple d’un réseau d’entreprise avec proxy
Le proxy est intercalé entre le réseau interne et Internet afin de filtrer les connexions entrantes et sortantes. Son but premier est d’appliquer des règles pour protéger le réseau de l’entreprise. Parfois le déchiffrement des connexions TLS est effectué sans que le client soit au courant. Parfois, l’entreprise ne sait même pas que son proxy possède cette fonction et qu’elle est activée.
3 Mise en évidence d’un « Man in the Middle »
Nous pouvons détecter ce type d’attaque en comparant le certificat « vu » par le client avec celui du serveur. Dans le cas normal, il n’y a qu’un seul certificat et son contenu est le même côté client et côté serveur. Mais si l’empreinte du certificat côté client diffère de celle du certificat du site consulté, cela veut dire que la communication est déchiffrée entre les deux extrémités !
Figure 6. Présentation du certificat avec ou sans proxy
Dans la figure 6, nous voyons que le certificat reçu par le client est celui du proxy. Dans un premier temps, ce proxy exécute la requête du client. Dans un second temps, il devient le client du site internet, et retransmet les réponses du site web au client en se faisant passer pour le serveur web.
4 Détection d’une interception de flux WEB chiffré
Dans le cadre d’un projet piloté par le laboratoire CVO de l’ESIEA, nous développons un démonstrateur qui permettra aux internautes de mettre en évidence un « Man in the Middle SSL ». Quand ce démonstrateur sera finalisé, tout internaute pourra savoir si le flux SSL entre son navigateur et un site WEB sécurisé est intercepté, voire modifié. À titre d’exemple, ce démonstrateur devra réagir si le logiciel Avast! est présent sur la machine de l’internaute. En effet, cet antivirus installe son propre certificat au-dessus de toutes les autorités reconnues afin de déchiffrer le flux TLS/SSL via un proxy local qu’il gère (cf. Article de David DeOliveira sur ce site). Sur le réseau d’une entreprise, l’employé pourra demander au Responsable des Systèmes d’Information (RSI ou DSI) les raisons qui l’ont poussé à installer un tel dispositif. Il pourra vérifier la conformité de la charte Internet. Il sera en tout cas conscient des risques quand il surfe de manière « sécurisée »..