Introduction correcte de l'inspection TLS sur Sophos Firewall

Une grande partie du trafic Web actuel est chiffrée. Sans inspection TLS, le pare-feu voit souvent uniquement l’IP de destination, le SNI, les informations de certificat et les métadonnées, mais pas le contenu réel de la connexion.

C’est un problème de sécurité : de nombreuses fonctions de protection ne peuvent pas ou très peu vérifier le contenu chiffré. L’analyse des malwares, la protection Web, l’analyse des menaces zero-day, le scan de contenu et certaines parties de la détection d’applications ou de menaces ne deviennent réellement efficaces que lorsque le pare-feu peut déchiffrer, vérifier et ensuite rechiffrer le trafic TLS. IPS et NDR bénéficient également d’une meilleure visibilité en clair. Sans déchiffrement, de nombreux signaux restent limités aux métadonnées, certificats, IP, domaines ou informations de protocole.

Cependant, l’inspection TLS n’est pas une fonctionnalité à activer sans préparation pour tous les utilisateurs. Elle peut perturber les applications, soulever des questions de confidentialité et alourdir le pare-feu. C’est pourquoi l’inspection TLS doit être introduite de manière planifiée, progressive et avec une stratégie d’exception claire.

Orientation

On commence par choisir la méthode de protection ou de configuration adaptée au cas réel. Cela évite les règles trop larges et les doublons lors du dépannage.

Licence et prérequis

Pour l’inspection TLS et l’évaluation efficace du trafic déchiffré, les licences de protection appropriées sont nécessaires.

Les plus importantes sont :

Web Protection : Inclut la sécurité Web, le contrôle Web, le contrôle des applications et la protection contre les malwares Web.
Network Protection : Inclut notamment IPS, Security Heartbeat et d’autres fonctions de protection réseau.
Zero-Day Protection : Devient importante lorsque les fichiers ou téléchargements doivent être analysés par apprentissage automatique ou sandbox.

La protection Web est incluse dans le bundle de licence Standard Protection. Xstream Protection et Epic Protection incluent également la protection Web et d’autres modules de protection. Pour la classification des bundles, voir Quels sont les bundles Sophos Firewall ?; pour la licence de base, le statut de support et les abonnements, voir Comprendre la licence de base Sophos Firewall.

Avant le déploiement, il convient de vérifier :

Le firmware actuel de Sophos Firewall est installé.
La protection Web est sous licence.
Le certificat CA du pare-feu est distribué sur les clients.
Un groupe de test ou un réseau de test est défini.
Le retour en arrière est documenté.
Le processus d’exception est clarifié.
La journalisation est activée.

Si le certificat CA n’est pas encore distribué, l’article Installer le certificat CA Sophos Firewall pour le scan HTTPS peut aider.

⚠️ L’inspection TLS peut perturber les applications qui utilisent le Certificate Pinning ou effectuent leurs propres vérifications de certificats. Le déploiement doit toujours commencer par un groupe de test et non directement avec tous les utilisateurs.

DPI ou Web Proxy ?

Sophos Firewall peut mettre en œuvre le déchiffrement HTTPS de deux manières :

Mode DPI : La règle de pare-feu utilise le moteur DPI. Les règles d’inspection SSL/TLS sous Rules and policies > SSL/TLS inspection rules décident de ce qui est déchiffré.
Mode Web Proxy : La règle de pare-feu utilise le proxy Web. Le déchiffrement HTTPS est alors contrôlé par les paramètres du proxy Web et les politiques Web.

Pour les configurations modernes, le mode DPI est souvent utilisé. L’important est la règle de pare-feu :

Ouvrir Rules and policies > Firewall rules.
Modifier la règle LAN-to-WAN concernée.
Ouvrir Security features > Web filtering.
Activer la politique Web appropriée.
Activer Scan HTTP and decrypted HTTPS.
Laisser Use web proxy instead of DPI engine désactivé si les règles d’inspection SSL/TLS doivent s’appliquer.

Si Use web proxy instead of DPI engine est activé, le trafic Web passe par le proxy Web. Dans ce cas, les paramètres de déchiffrement pour HTTP/HTTPS diffèrent de ceux des règles d’inspection SSL/TLS basées sur DPI. Avant le déploiement, il doit donc être clair si l’environnement utilise le proxy Web ou le DPI, sinon les exceptions seront recherchées au mauvais endroit.

Quel trafic doit être déchiffré ?

Il ne faut pas déchiffrer aveuglément tout le trafic. Une bonne inspection TLS commence par des objectifs clairs.

Objectifs initiaux pertinents :

LAN > WAN : trafic Web utilisateur classique vers Internet.
Wi-Fi > WAN : clients gérés dans le réseau Wi-Fi de l’entreprise.
VPN > WAN : utilisateurs d’accès à distance, si leur trafic Internet passe par le pare-feu.
LAN > DMZ : accès interne à ses propres serveurs, si une vérification de sécurité est souhaitée et que les certificats sont correctement distribués.

À traiter avec prudence :

Banques, santé, administrations et portails hautement sensibles.
Gestionnaires de mots de passe et fournisseurs d’identité.
Services de mise à jour des systèmes d’exploitation et des fabricants.
Applications mobiles et appareils Android.
Applications avec Certificate Pinning.
Services de voix, vidéo et collaboration, s’ils deviennent instables en raison du déchiffrement.

Pour les publications de serveurs depuis Internet vers la DMZ, l’inspection TLS n’est pas automatiquement la meilleure solution. Pour les serveurs Web, Protection des serveurs Web / WAF ou un proxy inverse est souvent plus approprié.

Prendre en compte QUIC et la politique Web

Si le trafic Web n’est pas vérifié comme prévu malgré l’inspection TLS, il convient également de vérifier QUIC ou HTTP/3. De nombreux navigateurs peuvent établir des connexions HTTPS via UDP 443. Selon la conception des règles et des politiques Web, le trafic ne passe alors pas par le chemin HTTPS classique attendu via TCP 443.

Dans les règles Internet des clients, il convient de vérifier consciemment :

La politique Web appropriée est-elle active ?
Block QUIC protocol est-il activé dans la règle de pare-feu réellement correspondante ?
Scan HTTP and decrypted HTTPS est-il défini en fonction de la stratégie de déchiffrement ?
La règle utilise-t-elle DPI ou Web Proxy ?
Voit-on dans le Log Viewer UDP 443, TCP 443, les événements de politique Web et les événements d’inspection SSL/TLS de manière cohérente ?

La procédure pour bloquer QUIC est décrite dans Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall. Pour la politique Web elle-même, voir Créer une politique de protection Web Sophos Firewall.

Planifier le rollout

TLS Inspection doit être introduite progressivement afin de garder exceptions, certificats clients et cas de support maîtrisables.

Stratégie de déploiement

Une approche progressive a fait ses preuves :

Distribuer le certificat CA.
Préparer la politique Web et la règle de pare-feu.
Sélectionner le profil de déchiffrement.
Définir un petit groupe de test.
Activer la règle d’inspection SSL/TLS uniquement pour ce groupe.
Observer le centre de contrôle et le Log Viewer.
Analyser les erreurs et documenter proprement les exceptions.
Étendre progressivement à d’autres groupes d’utilisateurs.

Cela permet de détecter tôt quelles applications posent problème, sans affecter l’ensemble de l’exploitation.

Planifier les phases de déploiement

Un déploiement d’inspection TLS doit être planifié en phases. Cela le rend contrôlable et permet de séparer les erreurs techniques des problèmes d’acceptation ou d’application.

Préparation: CA, politique Web, règle de pare-feu et groupe de test sont prêts. Distribution CA, licence, journalisation, retour en arrière
Pilote: quelques clients gérés testent le quotidien productif. Log Viewer, widget du tableau de bord, retour d’utilisateur
Extension: inclure d’autres groupes d’utilisateurs ou réseaux. Documenter les exceptions, observer la performance
Exploitation: L’inspection TLS est régulièrement vérifiée. Revue des exclusions, rapports, erreurs et nouvelles applications

Il est important que chaque phase ait un point d’arrêt clair. Si une application critique pour l’entreprise échoue lors du pilote, il ne faut pas immédiatement définir une exception globale large. Il est préférable de procéder à une analyse propre : quel domaine, quel client, quelle règle, quel profil de déchiffrement et quelle erreur dans le Log Viewer sont concernés ?

Définir le pilote, le propriétaire et le processus d’exception

Avant le premier déploiement en production, il doit être clair qui gère le groupe de test, qui approuve les exceptions et comment les erreurs sont signalées. L’inspection TLS génère sinon rapidement des exceptions désordonnées : des domaines individuels sont frénétiquement définis sur Don't decrypt, sans qu’il soit clair plus tard pourquoi l’exception existe.

Pour l’exploitation, ces points doivent être documentés :

Groupe pilote, réseaux concernés et période.
Propriétaire pour la politique Web, le profil de déchiffrement et les règles d’inspection SSL/TLS.
Processus pour les nouvelles exceptions avec raison, ticket et date de révision.
Critères pour savoir quand une application est exclue et quand la cause est d’abord examinée.
Lieu où le Log Viewer, le widget du tableau de bord et le retour d’utilisateur sont collectés.
Retour en arrière si des applications critiques pour l’entreprise sont perturbées.

Il est particulièrement important de distinguer entre une exception technique et une décision de sécurité permanente. Une exception temporaire peut être utile pour que le service fonctionne à nouveau. Cette exception doit cependant être réévaluée plus tard, une fois la cause, le risque et l’alternative clairs.

Tester le rollback avant le rollout

Un rollback ne doit pas être inventé seulement en cas d’incident. Avant le pilote, il doit être clair comment retirer TLS Inspection du groupe de test sans mélanger d’autres règles, Web Policies ou exceptions.

Contrôle pratique du rollback :

Retirer le groupe de test : vérifier que la SSL/TLS Inspection Rule ne matche plus le client pilote.
Désactiver la règle : contrôler que le trafic repasse par le chemin attendu sans déchiffrement.
Tester l’exception : une règle Don't decrypt ciblée doit se trouver au-dessus de la règle générale de déchiffrement et apparaître dans le Log Viewer.
Conserver la Web Policy : le rollback du déchiffrement ne doit pas supprimer accidentellement le web filtering, le malware scanning ou le logging.
Documenter la preuve : noter le client de test, le domaine cible, le nom de règle, l’événement de log et l’heure.

Ce test est particulièrement important lorsque plusieurs administrateurs travaillent sur les Web Policies, les règles de firewall et les SSL/TLS Inspection Rules. Un rollback propre ne retire que le scope concerné et ne rend pas toute la chaîne Web Protection aveugle.

Configuration

La configuration doit être précise, testable et facile à vérifier plus tard.

Comprendre les profils de déchiffrement

Un profil de déchiffrement détermine la rigueur avec laquelle le pare-feu traite les connexions TLS. Les profils se trouvent sous Profiles > Decryption profiles.

Un profil de déchiffrement répond notamment à ces questions :

Que se passe-t-il en cas de certificats invalides ou non fiables ?
Les anciennes versions de TLS sont-elles bloquées ?
Les suites de chiffrement non sécurisées sont-elles bloquées ?
Que se passe-t-il en cas de compression SSL ?
Que se passe-t-il en cas de suites de chiffrement non reconnues ?
Que se passe-t-il si le pare-feu ne peut pas déchiffrer une connexion ?
Quelle CA est utilisée pour la nouvelle signature ?

Pour un premier déploiement, un profil plus compatible est judicieux, par exemple Maximum compatibility ou un profil conservateur personnalisé. Pour les règles de sécurité en production, un profil plus strict comme Block insecure SSL peut être utilisé ultérieurement.

Important : Le profil de déchiffrement est sélectionné directement dans la règle d’inspection SSL/TLS. Le profil peut remplacer les paramètres globaux d’inspection SSL/TLS pour cette règle. C’est pourquoi, lors du dépannage, il faut toujours vérifier la règle concrète et non seulement les paramètres globaux.

Créer une règle d’inspection SSL/TLS

Le chemin de menu est Rules and policies > SSL/TLS inspection rules.

Une première règle doit être aussi ciblée que possible :

Action : Decrypt
Profil de déchiffrement : profil de test conservateur
Zones sources : LAN ou réseau de test
Réseaux et appareils sources : groupe de test ou sous-réseau de test
Zones de destination : généralement WAN
Réseaux de destination : initialement Any
Services : souvent Any pour commencer, car SSL/TLS peut également être reconnu sur d’autres ports TCP
Sites Web / Catégories : restreindre éventuellement

Les règles d’inspection SSL/TLS peuvent reconnaître les connexions TLS en dehors du port HTTPS classique. Les règles sont traitées de haut en bas. Les exceptions spécifiques et les règles pilotes doivent donc être placées au-dessus des règles générales de déchiffrement, sinon il sera difficile de comprendre pourquoi une connexion a été déchiffrée ou exclue.

Listes d’exclusion

Tout le trafic TLS ne doit pas être déchiffré. Sophos utilise pour cela des règles d’exclusion et des listes d’exclusion TLS.

Liste d’exclusion TLS locale

La liste d’exclusion TLS locale est la liste d’exclusion locale du pare-feu. Cette liste est vide par défaut et peut être remplie par le dépannage dans le centre de contrôle ou le Log Viewer.

Elle peut également être modifiée manuellement :

Web > URL groups > Local TLS exclusion list

Cette liste est utile pour les domaines qui posent problème dans votre propre environnement, par exemple en raison du Certificate Pinning ou d’applications clientes spécifiques.

Liste d’exclusion TLS gérée

La liste d’exclusion TLS gérée contient des exceptions maintenues par Sophos pour des services problématiques connus. Cette liste est mise à jour par les mises à jour du firmware.

Des exemples typiques sont des services pour lesquels l’inspection TLS cause généralement des problèmes ou n’est pas techniquement judicieuse.

Règles d’exclusion personnalisées

En outre, vous pouvez créer vos propres règles d’inspection SSL/TLS avec Action > Don’t decrypt. Celles-ci doivent être placées directement sous la règle d’exclusion par défaut et ne contenir que le trafic qui ne doit vraiment pas être déchiffré.

Critères possibles :

Catégories Web
Groupes d’URL
Utilisateurs et groupes
Réseaux source et destination
Adresses IP
Services

Les exceptions doivent être documentées : domaine, raison, utilisateurs concernés, date et date de révision.

Contrôle et analyse

Après l’activation, le dashboard et le Log Viewer montrent si le trafic est réellement déchiffré ou exclu.

Dans le centre de contrôle, il y a un widget pour l’inspection SSL/TLS. Ce widget est très utile pour surveiller le déploiement et les erreurs.

Il montre notamment :

Pourcentage de sessions SSL/TLS déchiffrées.
Pourcentage de sessions SSL/TLS non déchiffrées.
Autre trafic.
Erreurs des derniers jours.
Sites Web ou utilisateurs principaux avec des problèmes.
Pic de déchiffrement et limite de déchiffrement.

Sophos Firewall - Widget d'inspection SSL/TLS avec trafic déchiffré et non déchiffré — Sophos Firewall - Centre de contrôle > Widget d’inspection SSL/TLS

Si de nombreuses erreurs apparaissent dans le widget, il ne faut pas désactiver immédiatement toute l’inspection TLS. Il est préférable de vérifier les cibles concernées via Fix errors et de créer des exceptions propres si nécessaire.

Analyser le Log Viewer

Dans le Log Viewer, vous pouvez sélectionner le filtre SSL/TLS inspection. Vous y verrez ce qui s’est passé avec des connexions individuelles.

Sophos Firewall - Log Viewer avec événements d'inspection SSL/TLS — Sophos Firewall - Log Viewer > Inspection SSL/TLS

Les couleurs aident à une première évaluation :

Rouge : Erreur. La connexion n’a pas pu être correctement déchiffrée ou traitée. Vous devez vérifier les erreurs de certificat, les suites de chiffrement, les versions TLS ou les applications incompatibles.
Vert : Ne pas déchiffrer. La connexion n’a pas été déchiffrée intentionnellement, par exemple en raison d’une règle d’exclusion ou d’une liste d’exclusion TLS.
Bleu : Déchiffrer. La connexion a été déchiffrée puis retransmise chiffrée.

Le journal montre également le profil de déchiffrement, l’IP source, l’IP de destination, l’utilisateur, la catégorie et le domaine de destination. Cela permet de vérifier si la bonne règle correspond et si une exception est réellement appliquée.

Tests

Après l’activation de l’inspection TLS, vous devez vérifier :

Le certificat CA Sophos est-il utilisé dans le navigateur ?
Les applications métier importantes fonctionnent-elles ?
Y a-t-il des erreurs TLS dans le Log Viewer ?
Les événements de malwares ou de politique Web sont-ils correctement détectés ?
Le trafic est-il affiché comme déchiffré dans le widget du centre de contrôle ?
La performance du pare-feu reste-t-elle dans la plage attendue ?
Y a-t-il des plaintes des utilisateurs de test ?

Pour le dépannage, le Log Viewer, le Policy Test, la vue des certificats du navigateur, le Packet Capture et le widget d’inspection SSL/TLS sont particulièrement utiles.

Dépannage et exploitation

Les problèmes de TLS Inspection se résolvent généralement avec des exceptions claires, un rollback contrôlé et des revues régulières.

Erreurs typiques

Le navigateur affiche un avertissement de certificat: CA manquante dans le Trust Store ou mauvaise CA utilisée. Distribution CA, chaîne de certificats dans le navigateur, redémarrage du client
Le Log Viewer ne montre pas d’événements d’inspection SSL/TLS: mauvais mode, aucune règle correspondante ou moteur SSL/TLS non actif. Règle de pare-feu, DPI/Web Proxy, règle d’inspection SSL/TLS
Le trafic est autorisé mais non déchiffré: Règle Don't decrypt, exclusion gérée ou ordre de règle incorrect. Vérifier les règles d’inspection SSL/TLS de haut en bas
Le filtre Web ne fonctionne pas comme prévu: Politique Web manquante, QUIC actif ou Scan HTTP and decrypted HTTPS mal compris. Règle de pare-feu correspondante, QUIC, journal de politique Web
Certaines applications échouent: Certificate Pinning, ancienne version TLS, suite de chiffrement incompatible ou vérification de certificat propre. Log Viewer, profil de déchiffrement, exception ciblée
De nombreuses erreurs dans le widget du tableau de bord: déploiement trop large ou profil de déchiffrement inapproprié. Réduire le groupe pilote, trier les erreurs par domaine et catégorie
La performance diminue après l’activation: portée trop large, gros téléchargements ou trop de sessions simultanées. Vérifier la portée du déchiffrement, la charge du pare-feu et les principaux utilisateurs
L’exception ne fonctionne pas: L’exception est sous une règle de déchiffrement plus générale. Vérifier l’ordre des règles et les critères correspondants

Dans les cas peu clairs, il ne faut pas changer plusieurs choses à la fois. Il est préférable d’avoir un cas de test restreint : un client, un domaine cible, une règle de pare-feu, un profil de déchiffrement et un moment clair dans le Log Viewer.

Retour en arrière

En cas de perturbations, un retour en arrière clair doit être possible :

Désactiver la règle d’inspection SSL/TLS.
Retirer le groupe de test de la règle.
Assouplir le profil de déchiffrement.
Ajouter une exception pour le domaine ou l’application concernés.
Repasser la règle de pare-feu sur le proxy Web si cela est souhaité consciemment.

Les règles d’inspection SSL/TLS et le moteur SSL/TLS doivent être visiblement actifs pour que le centre de contrôle et le Log Viewer affichent les détails. Si vous désactivez l’inspection SSL/TLS à des fins de dépannage, vous devez la réactiver ensuite et documenter brièvement l’état.

Recommandation d’exploitation

L’inspection TLS n’est pas un projet en un clic. Correctement introduite, elle offre une visibilité considérablement accrue et améliore l’efficacité de la protection Web, du scan de malwares, de l’IPS, du NDR et des fonctions zero-day.

Pour les environnements de production, nous recommandons :

Commencer par LAN-to-WAN pour un petit groupe de test.
Distribuer correctement le certificat CA.
Choisir consciemment le mode DPI/Web Proxy.
Ne pas commencer avec un profil de déchiffrement trop agressif.
Observer quotidiennement le Log Viewer et le tableau de bord.
Documenter et vérifier régulièrement les exceptions.
Étendre le déploiement uniquement après des tests réussis.
Garder le rollback testé pour le groupe pilote et les exceptions.

FAQ

Faut-il activer immédiatement l'inspection TLS pour tous les utilisateurs ?

Non. L’inspection TLS doit commencer par un groupe de test. Ce n’est que lorsque la distribution du CA, la politique Web, le profil de déchiffrement, les exceptions, les journaux et les applications métier ont été vérifiés que l’on doit élargir la portée.

Pourquoi l'inspection TLS ne fonctionne-t-elle pas malgré le certificat CA installé ?

Le certificat CA assure uniquement que les clients font confiance à la CA du pare-feu. De plus, la règle de pare-feu, la politique Web, la règle d’inspection SSL/TLS, le profil de déchiffrement et l’ordre des règles doivent être corrects.

Quelle est la différence entre le mode DPI et le mode Web Proxy ?

En mode DPI, les règles d’inspection SSL/TLS s’appliquent au trafic de la règle de pare-feu. En mode Web Proxy, le trafic Web passe par le proxy et le déchiffrement est contrôlé différemment. Il est donc nécessaire de vérifier consciemment le mode de la règle de pare-feu concernée.

Quand a-t-on besoin d'une exception TLS ?

Une exception est utile lorsqu’une application ne peut pas être correctement déchiffrée en raison du Certificate Pinning, de sa propre vérification de certificat ou d’une incompatibilité technique. L’exception doit être documentée et réévaluée ultérieurement.

Faut-il bloquer QUIC pour l'inspection TLS ?

Dans les réseaux clients gérés, cela est généralement judicieux si le filtrage Web, le scan de malwares ou l’inspection TLS doivent s’appliquer de manière fiable. QUIC sur UDP 443 peut sinon contourner le chemin HTTPS classique attendu via TCP 443.