Dans Cisco Firepower Threat Defense, le SSL Decryption, c’est-à-dire déchiffrer le trafic HTTPS, permet d’appliquer la fonction AVC (Application Control Visiblity) ou bien AMP (Advanced Malware Protection) afin d’analyser les fichiers téléchargés par les utilisateurs avec le protocole HTTPS.
il existe deux méthodes pour mettre en place le SSL Decryption :
Decrypt-Resign : pour les connexions sortantes, c’est-à-dire déchiffrement du trafic émanant des utilisateurs internes vers des sites web et des serveurs externes. L’objectif est de protéger les hôtes internes. On dit que le firewall va faire une sorte d’attaque de l’homme du milieu afin de déchiffrer le trafic.
Decrypt-Known-Key : pour les connexions entrantes, c’est-à-dire déchiffrement du trafic émanant des utilisateurs externes vers des serveurs web interne de l’entreprise. L’objectif avec cette méthode est de protéger les serveurs web internes. On dit que le firewall va déchiffrer le trafic à la volée (in the fly).
Dans cet article, nous allons expliquer le principe de fonctionnement de la méthode Decrypt-Resign afin de comprendre :
- Comment le firewall va jouer le rôle de l’homme du milieu ?
- Comment va-t-il intercepter le trafic ?
- Comment va-t-il négocier les clés de sessions afin de le déchiffrer ?
Avec cette méthode, le défi du firewall est le fait qu’il ne possède pas les clés privées des serveurs externes (publique) puisque ces derniers ils ne sont pas sous le contrôle de l’entreprise.
La question qui peut effleurer l’esprit, pourquoi a-t-on besoin de la clé privée ? Parce que tout simplement, le firewall ne peut pas présenter le certificat réel, le vrai, du serveur externe, et cette clé privée est essentiellement utilisée en combinaison avec la clé publique. Ce couple Clé Privée et Clé Publique est utilisé pour échanger d’une manière sécurisée (à travers le SSL handshake) la clé de session qui sera utilisée ultérieurement pour protéger les données échangées entre l’utilisateur interne et le serveur externe.
En toute simplicité, l’algorithme asymétrique utilisant la paire clé privée / Clé Publique va protéger la clé de session de l’algorithme symétrique.
En principe, le SSL Handshake sans le firewall entre l’utilisateur interne et le serveur externe, par exemple mhd-expert.com s’opère comme suit :
Le client envoie un message SSL Client Hello proposant une liste d’algorithmes symétriques pris en charge et réclamant le certificat de mhd-expert.com :
Client PC à SSL Client Hello (proposal cipher : AES, 3DES + request certificat) àServer
Le serveur répond avec SSL Server Hello pour proposer l’algorithme symétrique qu’il souhaite utiliser et fournissant en même temps son certificat qui contient la clé publique K1 :
Client PC ß SSL Server Hello (chosen cipher AES + certificat + Clé Publique du serveur = K1) ß Server
Le PC va d’abord valider l’identité du serveur, en d’autres termes, il validera la signature du certificat en utilisant la clé publique de l’autorité de certification CA qui l’a signé.
Une la validation est faite, il faut passer à l’étape de négociation de la clé de session ou bien la clé secrète de l’algorithme symétrique AES négocié dans le SSL Handshake afin de l’utiliser pour crypter les données (requête et réponse web). Cette clé de session sera générée par le PC et envoyée au serveur en la cryptant avec la clé publique K1 contenue dans le certificat de ce serveur.
Client PC à (Je vous envoie la clé de session ou secrète en la cryptant avec votre clé publique K1) à Server
Le serveur décrypte le message avec sa clé privée et récupère ainsi la clé de session.
Ainsi le trafic web est échangé en toute sécurité à travers un tunnel SSL comme suit :
Client PC ß Les données sont cryptées avec l’algorithme AES en utilisant la clé de session à Server
En insérant le firewall au milieu, ce dernier va jouer le rôle de l’homme du milieu, pour le faire, le FTD va se comporter comme un CA en générant un certificat avec la clé publique et la clé privée ou bien il va s’appuyer sur un CA interne en uploadant le certificat racine avec la clé privée bien évidemment.
La question qu’on peut se poser, pourquoi a-t-on besoin de définir le firewall comme CA ?
Ce rôle va permettre au firewall de créer une copie du vrai certificat du serveur, en d’autres termes, il usurpera celui du serveur en créant un faux certificat avec les mêmes champs, surtout le même Common Name mais il le signera lui-même avec sa clé privée et il copie à l’intérieur sa clé publique (ou bien il le signera avec la clé privée du CA interne que vous avez uploadé et copiera la clé publique de ce dernier).
Et comme conséquence, il y’aura deux SSL Handshake :
- Entre le PC et le Firewall, ce dernier jouera le rôle de serveur
- Entre le Firewall et le serveur MDH-EXPERT, dans ce cas le firewall jouera le rôle du client
Client PC ß SSL handshake à (Serveur) Firewall (client) ß SSL handshake à Serveur MHD-EXPERT
Ainsi nous aurons deux certificats pour chaque connexion SSL :
- Le vrai certificat envoyé par le serveur MHD-EXPERT au firewall mais signé par une autorité externe Let’s Encrypt.
- Le faux certificat envoyé par le firewall au PC interne mais signé par le Firewall Lui-même (ou bien une autorité interne de l’entreprise).
Les deux certificats possèdent principalement en commun le même Common Name : mhd-experts.com mais, et c’est la que l’attaque de l’homme du milieu est mise en place, ils ont des clés publiques différentes.
Le vrai certificat contient la clé publique du serveur MHD-EXPERTS, tandis que le faux certificat contient la clé publique du firewall.
Finalement le processus du SSL Handshake dans les deux cotés est comme suit :
Client PC ß SSL handshake à (Serveur) Firewall (client) ß SSL handshake à Serveur MHD-EXPERT
Entre le firewall et le serveur MHD-EXPERTS :
Le serveur MHD-EXPERTS envoie son certificat, le firewall se comportant comme client le validera avec la clé publique de l’autorité de certification publique Let’s Encrypt.
Le Firewall en tant client génère une clé de session, on va l’appeler EK1, la crypte avec la clé publique de MDH-EXPERTS, ce dernier décrypte avec sa clé privée et récupère la clé de session EK1.
Entre le Firewall et le Client Interne :
Le firewall envoie un faux certificat se présentant comme MHD-EXPERT dans le Common Name et signé par le FTD (ou bien une autorité interne), le client interne le validera avec la clé publique du firewall ou bien la clé publique de l’autorité interne (d’où l’importance d’uploader le certificat du firewall ou bien le certificat racine de l’autorité interne dans le navigateur des PCs afin d’éviter le message « erreur de certificat ».
Le client interne génère une clé de session, on va l’appeler EK2, la crypte avec la clé publique du firewall (ou bien de l’autorité interne), le firewall par la suite décrypte avec sa clé privée et récupère la clé de session EK2.
Client PC ß (envoie EK1 crypté avec la clé publique du firewall ou du CA interne) à (Serveur) Firewall (client) ß envoie EK2 crypté avec la clé privée de MHD-EXPERTS à Serveur MHD-EXPERTS
Ainsi le SSL Decryption est en place :
Client PC ß Données cryptées et décryptés avec la clé EK1 à (Serveur) Firewall (client) ß Données cryptées et décryptés avec la clé EK2 à Serveur MHD-EXPERTS
