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

Chapitre 8

Des réflexes à avoir

Dans cette partie, je vous propose une liste des bonnes pratiques lors de la mise en place de l'interception TLS. Cette liste ne se serait être exhaustive car il existe beaucoup de solutions proposant cette fonctionnalité et chacune de ces solutions peuvent avoir des spécificités.

Nous verrons d'abord quelques pratiques à prendre en compte pour la partie technique, puis dans un second temps, les réflexes pour éviter les risques juridiques.

Edouard Petitjean M2 MIAGE SIID 50

Chapitre 9

La mise en oeuvre technique

Pour exposer les différentes pratiques, nous diviserons la partie technique en deux sections. L'une traitera de l'interception sortante, qui est plus complexe, la seconde portera sur l'interception entrante.

9.1 L'interception sortante

9.1.1 Gestion de l'AC interne

-- Utiliser une sous-autorité de certification dédiée à l'interception TLS dans le cas d'une utilisation d'une PKI.

-- Ne jamais utiliser les autorités de certification intégrées nativement dans les diverses solutions. C'est prendre le risque d'utiliser les mêmes clefs que les autres entités qui ont la même solution, ou utiliser un certificat obsolète.

-- Recenser toutes les solutions de navigation utilisées par les utilisateurs afin de prévoir un déploiement de certificat pour toutes ces solutions.

9.1.2 Protection des clefs privées

-- L'utilisation d'un HSM ¹ est fortement conseillée pour le stockage des clefs et leur utilisation. L'ANSSI propose une liste de solutions certifiées 2.

-- Revoir les droits systèmes liés aux fichiers contenant les clefs privées. Seul le service qui utilisera les clefs privées devrait avoir les droits de lecture sur ces clefs. Tous les autres accès provenant d'un autre service devront être prohibés.

9.1.3 Sécurité des connexions entre les clients internes et le proxy TLS

-- Limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Lors de la génération du certificat de l'AC utilisé par le proxy TLS ainsi que les certificats générés à la volée, il est conseillé d'utiliser des suites cryptographiques robustes. L'ANSSI a publié une annexe (RGS B1 ³) pour savoir comment choisir les bonnes suites cryptographiques.

-- L'utilisation du PFS (Perfect Forward Secrecy) est importante. Il permet de protéger les connexions passées en cas de compromission de la clef privée.

-- La désactivation de la compression permet d'éviter les attaques CRIME⁴ et ses variantes. -- Limiter le cache TLS afin de se prémunir d'une absence de vérification trop longue.

1. Hardware Security Module, est un composant matériel permettant la génération, stockage et protection des clefs cryptographique. Il permet également une protection lors de calcul cryptographique.

2. https://www.ssi.gouv.fr/entreprise/qualifications/

3. https://www.ssi.gouv.fr/uploads/2015/09/RGS\_B\_1.pdf

4. Compression Ratio Info-leak Made Easy, est une attaque se basant sur une vulnérabilité qui apparaît pendant l'utilisation de l'algorithme de compression DEFLATE.

Edouard Petitjean M2 MIAGE SIID 51

La mise en oeuvre technique - L'interception entrante

9.1.4 Sécurité des connexions entre le proxy TLS et les serveurs

-- Si possible, limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Si le point précédent bloque l'utilisation de certains sites distants, il faut utiliser une liste d'exception qui permettra un accès avec les versions TLS 1.0 ou SSL 3.0. Cela permet d'éviter d'autoriser ces versions à tout site alors que ces versions sont vulnérables.

-- Le comportement du proxy TLS en cas de présentation d'un certificat invalide par un serveur doit être personnalisable. A défaut, le proxy TLS devrait interdire toutes connexions utilisant des certificats invalides.

-- Il faut définir les suites cryptographiques utilisables ou non. A l'instar de la version du TLS, une liste d'exception devra pouvoir être définie pour autoriser des suites moins robustes.

-- La mise à jour régulière des suites cryptographiques est également importante pour faire face à l'évolution de la sécurité des sites distants.

-- Si la renégociation des sessions TLS est activée, elle doit être sécurisée⁵ afin d'éviter des attaques MITM

-- La désactivation de la compression permet d'éviter les attaques CRIME et ses variantes.

-- Vérifier lors de l'installation la liste des AC publiques connues par le proxy TLS. Il faut également pouvoir la mettre à jour quotidiennement.

9.1.5 Protection de la vie privée

-- Éviter de procéder au déchiffrement des sites personnels à moins que les conditions de sécurité ne l'exigent. Les sites relatifs à la gestion bancaire, médicale et à l'administration publique sont des sites qui ne devraient pas être interceptés au vu de la sensibilité des informations personnelles. Les messageries et les réseaux sociaux sont des sujets plus délicats. Leurs interceptions peuvent retourner de l'atteinte aux secrets des correspondances, mais ces sites restent les principales sources d'infections (téléchargement de fichier, mails malveillants) et de fuites de données (phishing), donc leurs interceptions peuvent se justifier dans une certaine mesure et dans un encadrement spécifique.

-- Si possible, éviter de déchiffrer les données qui sont explicitement identifiées comme personnelles, sans la présence de l'utilisateur, qui serait une atteinte à la vie privée.

-- La journalisation des flux déchiffrés doit rester cohérente avec la journalisation des flux non chiffrés. Seules les données nécessaires afin de garantir le bon fonctionnement du système et à l'identification des utilisateurs sont permises. La conservation des contenus des messages n'est pas autorisée.

-- Dans le cas d'une utilisation tierce d'analyse de flux (exemple : ICAP) qui recevrait le flux déchiffré, l'interconnexion entre ces deux éléments devra être sécurisée. Soit isolé physiquement en dédiant un lien direct entre le proxy TLS et la solution tierce, soit en prévoyant un chiffrement entre les deux équipements.

9.2 L'interception entrante

9.2.1 Sécurisation entre les clients externes et le reverse proxy TLS

-- Limiter l'utilisation du TLS aux versions 1.2 et 1.1, en proposant un ordre décroissant des versions.

-- Limiter l'utilisation des suites cryptographiques aux plus robustes. Les navigateurs évoluant plus vite, il ne seront pas bloqués par cette limitation cryptographique.

-- Si une renégociation des sessions TLS est nécessaire, le reverse proxy TLS ne doit accepter que celles qui sont sécurisées.

-- La désactivation de la compression permet d'éviter les attaques CRIME et ses variantes.

5. RFC 5746

Edouard Petitjean M2 MIAGE SIID 52

La mise en oeuvre technique - L'interception entrante

9.2.2 Protection des clefs privées

-- Un processus de gestion des certificats est nécessaire. Contrairement à l'interception sortante qui utilise un certificat d'autorité valable plusieurs années, les certificats serveur sont généralement valables un an. De plus, il faudra penser à la synchronisation du renouvellement des certificats sur les serveurs et le reverse proxy TLS.

-- L'utilisation d'un HSM est fortement conseillée pour le stockage des clefs et leur utilisation.

-- Revoir les droits systèmes liés aux fichiers contenant les clefs privées. Seul le service qui utilisera les clefs privées devrait avoir les droits de lecture sur ces clefs. Tous les autres accès provenant d'un autre service devront être prohibés.

Edouard Petitjean M2 MIAGE SIID 53