Introduction correcte de l'inspection TLS sur Sophos Firewall

Avec l’inspection TLS, Sophos Firewall met fin à la connexion cryptée du client et établit une deuxième connexion avec le serveur de destination. Il peut inspecter le texte en clair entre les deux. Le pare-feu re-signe pour le client un certificat serveur initialement digne de confiance avec sa propre CA (Certificate Authority). Si le client ne fait pas confiance à cette autorité de certification, il affiche un avertissement de certificat ou met fin à la connexion.

Cela permet d’inspecter le contenu déchiffré, notamment l’analyse antimalware et l’analyse de contenu. Sans décryptage, les fonctionnalités de protection peuvent être limitées, selon le module, à des informations telles que l’adresse IP, le domaine, le SNI, le certificat ou les métadonnées du protocole. Cela ne justifie pas un déploiement initial à grande échelle : l’épinglage des certificats, la confidentialité, la compatibilité des applications et la charge supplémentaire du pare-feu doivent être abordés avant le déploiement.

La version courte sûre est la suivante : déterminer s’il faut utiliser le chemin DPI ou proxy Web, distribuer l’autorité de certification de re-signature à un petit groupe, documenter l’état actuel, créer une règle de décryptage à portée étroite, exécuter un test positif et un test négatif, et n’étendre la portée qu’ensuite.

Décisions à prendre avant le pilote

Licence, CA et responsabilités

Les règles d’inspection SSL/TLS et les groupes d’URL qui y sont utilisés sont appliqués avec la licence Base License. Web Protection n’est pas une condition préalable générale à l’inspection TLS. Il est requis lorsque les catégories Web sont utilisées comme critères de règle ou lorsque les fonctionnalités de protection Web correspondantes sont nécessaires. Les inspections contre les logiciels malveillants, Zero-Day et autres nécessitent chacune l’abonnement correspondant. Quels packs Sophos Firewall sont disponibles ? et Comprendre la licence de base de Sophos Firewall expliquent les différences.

Clarifiez les points suivants avant de créer la première règle :

• Documentez la version SFOS utilisée, la licence disponible et le chemin d’inspection prévu.
• Définissez un groupe pilote géré et une fenêtre horaire claire. L’exemple ci-dessous utilise le client 10.20.30.50 du réseau de test 10.20.30.0/24 ; remplacez ces valeurs par vos propres objets.
• Obtenez l’approbation des parties prenantes responsables de la confidentialité pour la portée, la journalisation, la conservation et la notification des utilisateurs.
• Sauvegardez l’état initial exact de la règle de pare-feu, des règles TLS, du profil de décryptage, de l’autorité de certification et de tous les paramètres globaux. Consignez le parcours complet de correspondance avant le pilote, la règle qui correspondra après la désactivation du pilote (y compris toute règle Decrypt plus générale située plus bas), ainsi que chaque modification propre au pilote apportée aux règles de pare-feu, au mode DPI/proxy, à la politique Web et aux paramètres globaux. Définissez les étapes exactes de restauration autorisées avant l’activation.
• Désignez le propriétaire, les critères d’abandon, le processus d’exception et le chemin de restauration.

L’autorité de certification signataire doit se trouver dans le magasin de confiance des systèmes d’exploitation ou des navigateurs concernés. Vous pouvez également utiliser une autorité de certification d’entreprise subordonnée. Une autorité de certification de confiance publique n’est pas disponible à cet effet car le pare-feu re-signe les certificats pour les domaines tiers. Avec une autorité de certification externe, l’autorité de certification racine et l’autorité de certification subordonnée doivent être importées ; si l’autorité de certification signataire contient une section EKU, elle doit autoriser TLS Web Server Authentication. Installer le certificat d’autorité de certification Sophos Firewall pour l’analyse HTTPS décrit la distribution, tandis que Configurer une autorité de certification subordonnée pour l’inspection TLS de Sophos Firewall couvre la méthode d’autorité de certification d’entreprise.

⚠️ Ne commencez pas par tous les utilisateurs. Les appareils sans magasin de confiance gérable, le BYOD et les applications utilisant l’épinglage de certificat doivent initialement rester dans un périmètre distinct. Une exception rétablit la connexion, mais supprime son contenu du déchiffrement.

Gardez le DPI et le proxy Web séparés

SFOS utilise le DPI engine par défaut. Sur ce chemin, le pare-feu traite d’abord la règle de pare-feu, puis les règles d’inspection SSL/TLS. La règle d’inspection elle-même n’autorise pas le trafic : même Services: Any signifie uniquement que le trafic TLS déjà autorisé par la règle de pare-feu sur n’importe quel port TCP est éligible pour cette règle d’inspection.

Pour le chemin DPI, ouvrez Rules and policies > Firewall rules, modifiez la règle LAN-to-WAN appropriée et vérifiez Security features > Web filtering :

1. Laissez Use web proxy instead of DPI engine désactivé.
2. Sélectionnez une politique Web uniquement si la protection prévue l’exige ; ce n’est pas une condition préalable à la règle de décryptage.
3. Scan HTTP and decrypted HTTPS permet d’analyser les logiciels malveillants pour HTTP et HTTPS déjà déchiffrés. L’option elle-même n’active pas le décryptage HTTPS.

Dans Web Proxy Mode, le proxy gère le déchiffrement HTTPS. Decrypt HTTPS during web proxy filtering est le paramètre pertinent sur le chemin du proxy. Les règles DPI sous Rules and policies > SSL/TLS inspection rules ne s’appliquent pas aux connexions déchiffrées par le proxy Web. Avec le proxy transparent, les ports 80 et 443 passent par le proxy tandis que SSL/TLS sur les autres ports peuvent toujours être gérés par le chemin DPI ; avec le proxy explicite, le proxy Web effectue le décryptage.

Les autorités de certification sont également distinctes : DPI utilise l’autorité de certification des paramètres SSL/TLS ou du profil de décryptage sélectionné. Le proxy Web utilise l’autorité de certification de Web > General settings. Lors d’un changement de mode, vérifiez non seulement les règles mais également l’autorité de certification réellement présentée. Choisissez correctement le moteur DPI ou le proxy Web explique les différences plus en détail.

Ce chemin d’inspection sortant n’est pas destiné aux serveurs Web publiés sur Internet. Web Server Protection / WAF ou un proxy inverse est généralement l’architecture la plus appropriée. Les règles d’inspection SSL/TLS s’appliquent au trafic sortant, de sorte que seules les zones internes peuvent être sélectionnées comme Source zones. Elles détectent TLS sur n’importe quel port TCP, mais ne sont pas appliquées sur UDP.

Contradiction documentaire sur le sens du trafic : Le guide de création des règles mentionne les connexions entrantes et sortantes, puis limite explicitement Source zones aux zones internes et au trafic sortant. La formulation générale ne démontre pas une inspection entrante depuis le WAN. Ce déploiement reste sur le parcours des clients internes décrit ici ; les connexions entrantes vers un serveur nécessitent une clarification auprès de Sophos Support pour le build utilisé avant toute modification.

Le routage, DNS et l’accès Internet autorisé doivent déjà fonctionner avant le test de déchiffrement. Sous Rules and policies > NAT rules, vérifiez la règle SNAT qui correspond réellement ; dans une architecture IPv4 classique, il peut s’agir de Default SNAT IPv4 avec Translated source (SNAT): MASQ. Ne remplacez pas une règle fonctionnelle par une autre règle NAT trop large. IPv6 et les réseaux routés nécessitent une décision d’architecture propre, pas automatiquement MASQ. La règle de pare-feu du pilote nécessite Action: Accept et le périmètre source, destination et services approuvé.

Pour le proxy, vérifiez également HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols et Block invalid certificates sous Web > General settings > HTTPS decryption and scanning. Pour Direct Proxy, n’autorisez le listener configuré sous Web > General settings > Web proxy configuration et Administration > Device access > Other services > Web proxy que pour les clients ou zones nécessaires. Le proxy transparent nécessite les services HTTP/HTTPS ; Direct Proxy nécessite aussi le port du listener configuré. L’article DPI/proxy déjà lié détaille le parcours complet et la protection des services Web locaux du pare-feu.

Exemple de compatibilité obsolète : Le guide de configuration conservé pour SFOS 22/23 demande TLS 1.1 dans son exemple de proxy, alors que la documentation des profils considère les versions antérieures à TLS 1.2 comme non sûres. TLS 1.1 n’est donc pas retenu comme exigence de déploiement. Conservez des protocoles sûrs ; si une application ancienne nécessite une exception, clarifiez d’abord la version, le parcours concerné, le risque et le périmètre étroit avec le responsable du pare-feu. Abaisser TLS globalement n’est pas une solution pour le pilote.

Gérer QUIC de manière délibérée

QUIC, ou HTTP/3, utilise UDP. Block QUIC protocol dans une règle de pare-feu rejette les paquets UDP sortants vers les ports 80 et 443 dans la portée de cette règle, incitant normalement les clients disposant d’une solution de repli TCP utilisable à réessayer via TCP ; les clients qui n’en disposent pas peuvent perdre leur connectivité. SFOS sélectionne l’option par défaut dès qu’une stratégie Web est sélectionnée dans la règle ou que Scan HTTP and decrypted HTTPS est activé. Ce paramètre s’applique par règle, et non globalement, alors vérifiez la règle de pare-feu qui correspond réellement. Cette option ne couvre pas le trafic UDP sur d’autres ports. Vérifiez l’établissement effectif d’une connexion TCP, le fonctionnement de l’application et la correspondance avec le parcours d’inspection prévu ; le seul blocage d’UDP ne prouve aucun de ces éléments.

Ce filtre Web ne peut pas analyser QUIC. Cela ne signifie pas que tous les autres contrôles du pare-feu sont contournés, mais le chemin TCP TLS et le filtre Web attendus ne s’appliquent pas. Bloquer correctement QUIC et HTTP/3 sur Sophos Firewall affiche le test de règle ; Création d’une stratégie de protection Web du pare-feu Sophos couvre la stratégie Web.

Sélectionnez le périmètre par objectif et risque

Le point de départ habituel est le trafic utilisateur géré de LAN à WAN. Un réseau Wi-Fi d’entreprise distinct peut ensuite être ajouté avec Wi-Fi > WAN. Pour l’accès à distance, VPN > WAN n’est pertinent que lorsque le trafic Internet des utilisateurs traverse réellement le pare-feu via un tunnel complet. Incluez les connexions internes de LAN vers une DMZ uniquement lorsque l’inspection du contenu présente un avantage évident et que le client fait confiance à l’autorité de certification de re-signature tandis que le pare-feu valide la chaîne de certificats d’origine du serveur. Les serveurs de destination ordinaires n’ont pas besoin que cette autorité de certification d’inspection soit installée. Évaluez séparément la compatibilité du TLS mutuel (mTLS).

La compatibilité technique et l’autorisation de décryptage sont des décisions distinctes. Les portails bancaires, de santé et gouvernementaux, les gestionnaires de mots de passe, les fournisseurs d’identité, les mises à jour du système d’exploitation et des fournisseurs, ainsi que les services vocaux, vidéo et de collaboration nécessitent une évaluation fonctionnelle et de confidentialité avant leur inclusion. L’épinglage ou l’échec d’un pilote ne justifie pas une exception générale pour une catégorie entière : identifiez d’abord la source, le domaine et l’application réellement requis.

Configurer un pilote complet

Pour un pilote pouvant être testé directement, nous utilisons ces exemples de valeurs :

• Client pilote : 10.20.30.50 du réseau de test documenté 10.20.30.0/24
• Règle de pare-feu : LAN to WAN - TLS pilot
• Règle d’inspection SSL/TLS : TLS decrypt pilot client
• Zone source : LAN, Zone destination : WAN
• Réseaux et services de destination : Any
• Action : Decrypt
• Profil de décryptage : initialement Block insecure SSL ou un profil pilote qui en dérive
• Journalisation : Log connections activé pour le pilote

10.20.30.0/24, l’adresse IP de l’hôte et les noms d’objet sont des exemples. La source de production doit être suffisamment étroite pour identifier un client sans ambiguïté. Any pour la destination et le service facilite l’observation de TLS en dehors de TCP 443 pendant le pilote ; cela n’étend pas ce que permet la règle de pare-feu précédente. Si l’inspection n’est autorisée que pour un groupe de destination spécifique, ajoutez un groupe d’URL ou un autre critère de destination approprié.

Sélectionnez un profil de décryptage

Sous Profiles > Decryption profiles, trois profils par défaut non modifiables sont disponibles :

• Maximum compatibility maximise la compatibilité et ne restreint pas les chiffrements.
• Block insecure SSL bloque les chiffrements faibles et autorise le trafic qui ne peut pas être déchiffré.
• Strict compliance applique des exigences strictes, y compris des exigences basées sur PCI DSS.

Maximum compatibility peut aider à isoler temporairement un client problématique, mais ses contrôles souples le rendent inadapté comme critère d’acceptation de la production. Pour le pilote, Block insecure SSL ou un profil délibérément dérivé est le point de départ le plus transparent. Tolérez les anciennes versions TLS ou les clés RSA de moins de 2048 bits uniquement pour un serveur hérité clairement identifié et dans le cadre d’une règle à portée étroite.

Rejet des mécanismes hérités avec Decrypt : Avec Action: Decrypt, Sophos Firewall rejette toujours les connexions utilisant SSL 2.0 and SSL 3.0, SSL compression ou Unrecognized cipher suites, même si le profil sélectionne Allow without decryption pour ces éléments. Une autorisation explicitement approuvée et à portée étroite pour un système hérité exige à la fois Allow without decryption dans les champs concernés du profil et Action: Don’t decrypt ; l’autorisation dans le profil ne suffit pas à elle seule.

Un profil personnalisé peut remplacer les paramètres SSL/TLS globaux. Les options d’autorité de certification de re-signature sont Use CAs defined in SSL/TLS settings, Re-sign RSA with et Re-sign EC with. Pour le trafic qui ne peut pas être déchiffré, les options sont Use SSL/TLS settings default, Allow without decryption, Drop et Reject. La référence globale par défaut ne s’applique pas à Unrecognized cipher suites ; ce cas doit être évalué explicitement dans le profil. Selon le paramètre, les erreurs de certificat, la taille RSA minimale, les versions TLS et les chiffrements bloqués utilisent Drop, Reject ou Reject and notify comme Block action.

L’inspection ne rend pas digne de confiance un certificat de serveur auto-signé ou avec une chaîne incomplète. Au lieu de l’exclure à la hâte, vérifiez d’abord le nom d’hôte, le certificat original et la chaîne complète.

Pour un original auto-signé, le pare-feu remplace la clé et signe avec celle-ci, pas en tant qu’autorité de confiance : le client voit toujours un certificat auto-signé. Si la chaîne complète vers une CA reconnue par le pare-feu manque, un certificat généré par le système est utilisé, dont le CN explique le problème. Un avertissement ne signifie donc pas automatiquement un échec de distribution de la CA.

Créez un profil personnalisé sous Profiles > Decryption profiles > Add, avec un nom et une description, ou clonez un profil adapté ; enregistrez-le puis affectez-le à la règle d’inspection. Les certificats originaux RSA et EC peuvent souvent utiliser la même CA signataire. Si une application exige un type de clé précis, sélectionnez la CA correspondante sous Re-sign RSA with ou Re-sign EC with. Téléchargez chaque CA réellement utilisée avec le bouton à côté de la sélection ; si deux CA distinctes sont utilisées, les clients doivent faire confiance aux deux.

Avant d’enregistrer, examinez Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version et Cipher algorithms to block. TLS inférieur à 1.2 et RSA inférieur à 2048 bits ne sont pas des valeurs sûres. Maximum supported autorise la version maximale prise en charge. Le contrôle Revoked nécessite une CRL importée (Certificate Revocation List) ; cocher la case ne prouve pas à lui seul que le contrôle de révocation fonctionne. Une Web Exception pour HTTPS decryption peut autoriser des connexions correspondantes avec des certificats invalides : ce n’est donc pas une simple correction de l’épinglage.

Les erreurs de certificat comprennent Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch et Invalid for other reasons. Name mismatch compare le nom du serveur dans Client Hello aux noms du certificat. Pour choisir les chiffrements bloqués, évaluez séparément l’échange de clés, l’authentification, les chiffrements de données et les algorithmes de hachage. La compression SSL avant chiffrement présente des vulnérabilités connues ; les chiffrements inconnus ne peuvent pas être déchiffrés.

Les valeurs globales se trouvent sous Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. TLS 1.3 decryption propose Decrypt as 1.3 et Downgrade to TLS 1.2 and decrypt. La seconde option affecte toutes les règles d’inspection SSL/TLS ; n’abaissez pas TLS globalement pour un pilote normal.

When SSL/TLS connections exceed limit détermine le comportement lorsque la capacité de déchiffrement est épuisée : Allow without decryption préserve l’accès, mais supprime l’inspection du contenu ; Drop rejette silencieusement, tandis que Reject envoie un reset. C’est un arbitrage explicite entre disponibilité et protection pour le pilote, pas seulement une valeur de performance. Reject and notify tente d’afficher une page de blocage HTTPS avec la raison de l’erreur sans le garantir ; il empêche le transfert de données vers le serveur.

Avec TLS 1.3, les erreurs de certificat, la taille RSA minimale, une rétrogradation globale et Reject and notify se comportent comme documenté uniquement avec Action: Decrypt. Avec Don’t decrypt ou Deny, Reject est utilisé à la place pour cette gestion de profil. Une rétrogradation globale vers TLS 1.2 introduit un risque de sécurité et ne constitue pas un correctif de compatibilité général.

Créez la règle et vérifiez son ordre

Sous Rules and policies > SSL/TLS inspection rules > Add, définissez les champs comme suit :

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, la règle pilote précède donc les règles de décryptage générales personnalisées
3. Action: Decrypt
4. Log connections: activé pour la surveillance pilote
5. Decryption profile: le profil pilote sélectionné
6. Source zones: LAN
7. Source networks and devices: objet hôte pour 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: vide ou limité à la portée de destination approuvée

Log connections est facultatif et n’est pas obligatoire pour que la règle fonctionne. Il est néanmoins utile pour un pilote limité dans le temps car la négociation TLS et la fermeture de la connexion peuvent être tracées. La conservation doit respecter la politique de confidentialité et d’exploitation convenue.

Le tableau est évalué de haut en bas et le traitement s’arrête à la première correspondance. Tous les critères configurés doivent correspondre simultanément. La règle par défaut fixe Exclusions by website or category reste en haut et ne peut pas être précédée de la sélection de Rule position: Top. Placez les exceptions Don't decrypt personnalisées immédiatement en dessous, suivies de règles pilotes spécifiques et, enfin, de règles de décryptage plus larges.

Les critères d’utilisateur et de groupe ne sont fiables que si SFOS connaît le contexte utilisateur de la connexion. Si cela n’est pas garanti, commencez par un hôte ou un objet réseau sans ambiguïté et ajoutez des critères d’identité uniquement après un test de correspondance distinct.

Après Save, revérifiez l’état et la position de la règle dans le tableau. More options permet de modifier, cloner, insérer à côté d’une règle et supprimer ; Rule handle change l’ordre. Les filtres Source, Destination ou Rule ID facilitent la comparaison ; Reset filter réaffiche tout le tableau. Action: Deny empêche l’établissement de la connexion et n’équivaut pas à Don’t decrypt. Categories and websites est identifié grâce au SNI dans la négociation TLS. Les nouvelles installations activent les règles d’inspection SSL/TLS par défaut, mais leur état réel reste une vérification préalable.

Distinguer les configurations TLS via l’API XML

Dans les déploiements automatisés, l’Inspection Rule, les paramètres DPI globaux et la configuration du scanning HTTP/HTTPS sont trois objets distincts. La sélection d’une CA n’active ni la règle pilote ni le scanning dans la Firewall Rule. Les correspondances ci-dessous concernent la structure des objets pour SFOS 22 et 23. Avant toute écriture, l’opération explicite et la charge utile complète sont confirmées dans API help du build installé. L’autorisation des sources, le compte, la vérification TLS, les secrets et la distinction entre succès HTTP et statut XML sont expliqués dans Limiter de manière sûre l’accès à l’API XML et vérifier les réponses.

Inspection Rule : identité, hiérarchie et ordre

L’objet s’appelle SSLTLSInspectionRule. Son champ direct Name désigne la règle ; dans l’exemple, NewName est le nom modifié pour un renommage, et non le nom de la règle de référence pour un déplacement. Pour le nom de la règle, la documentation indique un maximum de 60 caractères, l’encodage UTF-8 et l’absence de virgule ; Description est limité à 255 caractères. IsDefault est en lecture seule et ne sert pas à transformer une règle pilote personnalisée en règle par défaut.

Les champs de correspondance restent sous leurs parents respectifs, même si le tableau des paramètres mentionne plusieurs fois le même nom d’enfant :

• SourceZones > Zone et SourceNetworks > Network : zone source interne et objet hôte pilote approuvé.
• DestinationZones > Zone et DestinationNetworks > Network : zone de destination et objets de destination autorisés.
• Identity > Members : utilisateurs ou groupes sources, uniquement avec une correspondance d’identité vérifiée.
• Services > Service : objets de service pour le périmètre approuvé.
• Websites > Activity > Name et Websites > Activity > Type : nom et type du critère de site web ; l’exemple cite Web Category et URL Group.
• MoveTo > Name et MoveTo > OrderBy : règle de référence et position relative ; OrderBy utilise Before ou After.

Zone, Network, Service et les activités de site web peuvent apparaître plusieurs fois. Un champ Name ou Network à plat, sans le bon nœud parent, ne remplit pas la même fonction. Les noms des objets sont repris de la configuration existante ; le périmètre et le profil ne sont pas remplacés par des champs absents ou des valeurs par défaut non vérifiées.

Position utilise Top ou Bottom et sert uniquement au placement initial lors d’un ADD. En l’absence d’indication, l’exemple mentionne Bottom ; pour UPDATE ou APIImport, Position n’est pas requis et n’est pas retenu ici comme mécanisme de déplacement. Le champ facultatif MoveTo est appliqué lors de l’ADD après Position. Si les deux sont définis, il faut donc vérifier la position relative résultante, et pas seulement la valeur Top initiale. L’exclusion par défaut fixe reste tout en haut ; l’ordre décrit précédemment pour les exceptions approuvées, les règles pilotes et les règles Decrypt plus larges reste applicable.

Les champs directs Enable, LogConnections, DecryptAction et DecryptionProfile ont des fonctions distinctes : état de la règle, journalisation, décision de déchiffrement et affectation du profil. Pour Enable, le tableau indique Yes, No, t, f ; pour LogConnections, Enable, Disable, t, f. DecryptAction utilise exactement Decrypt, Do not decrypt ou Deny. Le libellé d’interface Don’t decrypt n’est donc pas une valeur XML à utiliser sans vérification. Le profil choisi est affecté sous DecryptionProfile avec son nom réel ; une Source étroitement délimitée et le périmètre complet de destinations/services approuvé restent obligatoires, même en cas d’automatisation.

Les lignes de statut XML propres à l’objet distinguent l’opération et le symbole :

Message.* reste ici un identifiant documentaire non résolu, et non un texte garanti à l’exécution ni une cause d’erreur définitive. Avant chaque nouvelle tentative, la réponse expurgée et l’état réellement enregistré sont comparés : nom de règle initial ou nouveau, état, critères complets, DecryptionProfile et position par rapport aux autres règles. Même une ligne 200 ne remplace ni cette comparaison ni le test avec de nouvelles connexions. Si l’état est incertain, arrêter et clarifier la situation, plutôt que de créer une deuxième règle ou une règle plus large par un nouvel ADD ou une autre position.

Paramètres DPI globaux : la CA n’est pas un commutateur d’activation/désactivation

Sous SSLTLSInspectionSettings, RSACA et ECCA correspondent directement à la sélection de la CA de re-signature pour les certificats serveur RSA et EC, respectivement. Ils référencent des objets CA, et non des chemins de fichiers ou des valeurs d’activation. Le profil peut remplacer la sélection de CA pour sa règle. Avant un changement, le profil, la CA réellement présentée, la confiance des clients et la chaîne racine/subordonnée sont donc vérifiés ensemble ; si différentes CA sont utilisées, les clients doivent faire confiance aux deux.

Les champs globaux directs SSLTLSEngine et SSLTLSInspection sont distincts de cette sélection et utilisent chacun Enabled ou Disabled. Le premier contrôle la TLS engine, le second la SSL/TLS Inspection globale, et non l’état d’une règle pilote individuelle. La désactivation de l’inspection empêche l’application des règles et l’affichage des détails de connexion/déchiffrement dans Control Center et Log viewer. La désactivation du moteur retire également du chemin l’application de la politique web DPI au trafic HTTPS ; le déchiffrement HTTPS par proxy n’est pas affecté. Aucune de ces deux actions ne constitue un retour arrière normal du pilote.

TLS13Decryption se trouve également directement sous SSLTLSInspectionSettings et utilise Decrypt as 1.3 ou Downgrade to TLS 1.2 and decrypt. Ce champ sélectionne le traitement global de TLS 1.3, et non la CA de signature ni l’action d’une règle individuelle. Une rétrogradation concerne toutes les Inspection Rules et n’est pas mise en place comme correction de compatibilité pour un seul client. Les limites déjà expliquées pour TLS 1.3 et Action: Decrypt restent déterminantes.

Les autres champs directs SSLv2SSLv3, SSLCompression et SSLConnectionsExceeded utilisent chacun Allow without decryption, Drop ou Reject. Ils concernent des cas différents et ne sont pas assimilés à DecryptAction. Après une modification autorisée, les valeurs globales enregistrées, les substitutions définies dans les profils et le chemin réel du pilote sont vérifiés. Seules les modifications documentées liées au pilote sont rétablies à leur état antérieur exact, sans désactivation généralisée des contrôles.

Scanning HTTP/HTTPS : tenir compte de son nœud parent propre

L’objet distinct AntiVirusHTTPsConfiguration contient directement ScanMode, FileSizeThreshold, AudioVideoFileScanning et PUADetection. Dans le nœud enfant HTTPSConfigurations se trouvent en revanche HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate et NoHttpsNotification. HTTPSScanningCA appartient donc à la configuration HTTP/HTTPS du chemin proxy, et non à RSACA ou ECCA des paramètres DPI. Ces champs ne remplacent ni la correspondance de règle DPI ni Decrypt HTTPS during web proxy filtering dans la Firewall Rule appropriée. Le contexte du scanning est expliqué dans Comprendre le scanning antimalware sur Sophos Firewall.

ScanMode indique RealTime et BatchMode. FileSizeThreshold est exprimé en KB ; le tableau indique une plage de 1 à 1572864, un maximum de 7 chiffres et la valeur par défaut 1024. Les fichiers dépassant le seuil ne sont pas analysés ; la valeur par défaut documentée n’est pas une recommandation pour tous les environnements.

Contradiction non résolue entre les valeurs : Pour AudioVideoFileScanning, l’exemple XML montre Enable/Disable, tandis que le tableau des paramètres indique on/off et la valeur par défaut Disable. Aucun alias interchangeable n’en est déduit. Pour DenyUnknownProtocol et AllowInvalidCertificate également, l’exemple montre Enable/Disable, alors que le tableau n’indique que on et on/off, respectivement ; pour PUADetection, il contient des valeurs symboliques. Avant toute modification automatisée, API help ou le Support doit confirmer les valeurs valides pour l’objet et le build concernés. Sans clarification, ne pas exécuter la requête d’écriture concernée ; ne pas assouplir les contrôles des certificats pour permettre un import.

Après une modification approuvée, la sélection de CA et les contrôles enregistrés sous Web > General settings, le chemin proxy/DPI effectivement utilisé pour la correspondance et l’émetteur du certificat visible sont comparés à l’état antérieur. Ce n’est qu’ensuite que sont effectués le test fonctionnel, le test positif et le test négatif des exceptions. Une configuration de scanning formellement acceptée ne prouve ni le déchiffrement ni l’efficacité du scanning antimalware.

Limitez les exceptions

La règle par défaut Exclusions by website or category utilise Don’t decrypt avec Maximum compatibility et reste en première position. La liste Local TLS exclusion list est vide par défaut ; la liste Managed TLS exclusion list contient des sites incompatibles connus et est maintenue via des mises à jour du micrologiciel.

Modifiez la liste locale à :

Web > URL groups > Local TLS exclusion list

Les groupes d’URL ou les correspondances SNI sont plus efficaces pour les exceptions de domaine que de nombreux hôtes FQDN. Selon Sophos, par exemple, 200 hôtes FQDN entraînent 200 recherches pour chaque nouvelle connexion SSL/TLS. La restriction sur les exceptions Source/Destination combinées doit être distinguée de la correspondance normale des règles. Créer et utiliser des groupes d’URL en toute sécurité explique la portée du domaine, les caractères génériques et les tests négatifs.

Une règle d’inspection SSL/TLS personnalisée avec Action: Don’t decrypt doit enregistrer le domaine, la source concernée, la raison, le ticket, le propriétaire et la date de révision. Don’t decrypt n’est pas un contournement inconditionnel : les restrictions du profil de décryptage sélectionné s’appliquent toujours. Pour autoriser SSL 2/3, la compression ou les chiffrements inconnus pour un cas hérité explicitement approuvé, utilisez un profil avec Allow without decryption avec Action: Don’t decrypt. Cette combinaison n’appartient pas à une règle générale d’Internet.

Les exclusions SSL/TLS et les exceptions Web résolvent différents problèmes. Une exception TLS contrôle le décryptage sur n’importe quel port TCP en mode DPI. Une exception Web modifie les vérifications de stratégie Web sélectionnées ; en mode proxy, cela affecte le chemin proxy concerné. Avant d’effectuer une modification, déterminez si le décryptage ou uniquement une vérification Web doit être exclu. Créer et tester des exceptions Web en toute sécurité affiche le flux de travail de sélection et d’expression régulière.

Périmètre d’exception incertain : Le guide d’exclusion de sites indique que les exceptions Source et Destination ne peuvent pas être combinées ; le guide des règles propose les deux champs de correspondance. Cela ne démontre pas qu’une Web Exception combinant les IP source et destination est autorisée. Conservez la restriction source du pilote avec un nom d’hôte confirmé ou un URL Group. Si les deux critères d’exception IP sont également indispensables, n’activez ni n’élargissez l’exclusion avant une clarification de Support propre au build. Ne supprimez pas un critère simplement pour obtenir une correspondance.

Pour un cas ancien expressément approuvé, créez un profil tel que Allow_non-decryptable_profile sous Profiles > Decryption profiles > Add. Seuls les champs nécessaires — SSL 2.0 and SSL 3.0, SSL compression ou Unrecognized cipher suites — reçoivent Allow without decryption. Sous Rules and policies > SSL/TLS inspection rules > Add, affectez le profil à une règle Don’t decrypt étroite, avec la source du pilote, un périmètre source interne, la destination appropriée et une cible connue. Il s’agit d’une réduction de protection pour un cas ancien justifié, pas d’une autorisation générale de ces protocoles.

En l’absence de SNI exploitable, un URL Group ou une regex de domaine ne peut pas identifier la cible. Après vérification du flux réel, un IP Host étroit sous Destination networks peut convenir ; un FQDN Host reste une solution fondée sur DNS avec les coûts indiqués. Pour une regex, un début ancré ^ et un test négatif sont importants ; les caractères génériques larges peuvent aussi ralentir le traitement. Le lien Web Exceptions ci-dessus explique la syntaxe sûre complète et la différence avec une liste de domaines.

Prise en charge d’Android avec une portée étroite

Certaines connexions Android utilisent l’épinglage de certificat. La vérification de la connectivité, le Play Store ou les mises à jour peuvent alors échouer sous le décryptage. Le workflow documenté par Sophos utilise un VLAN ou un réseau sans fil isolé et un groupe d’hôtes FQDN contenant :

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• le domaine Google local, par exemple *.google.ch en Suisse

Créez le groupe sous Hosts and services > FQDN host group > Add. Sous Hosts and services > FQDN host > Add, créez un hôte par domaine et affectez-le directement au groupe. Créez un nouveau réseau sans fil Sophos sous Wireless > Wireless networks > Add, puis son objet réseau sous Hosts and services > IP host > Add, avec IP version: IPv4, Type: Network, votre adresse réseau et votre masque. Pour un VLAN ou réseau sans fil isolé existant, utilisez son objet approprié plutôt que de créer un réseau sans besoin confirmé. Confirmez la zone d’entrée réellement affectée à cette interface ou à ce VLAN ; Wi-Fi est l’exemple de réseau sans fil Sophos, et non une exigence pour tous les réseaux mobiles.

La documentation générale recommande une exception pour tous les appareils Android ; le parcours concret la limite aux destinations Google dans un réseau mobile isolé. Ce déploiement suit le parcours plus étroit avec tests positifs et négatifs, pas un contournement global pour toutes les connexions Android. Passer au Web Proxy est une décision d’architecture distincte, pas une correction automatiquement équivalente de l’épinglage.

Au-dessus de la règle générale de décryptage, ajoutez une règle d’inspection SSL/TLS avec Action: Don’t decrypt, Decryption profile: Maximum compatibility, Source zone définie sur la zone d’entrée réelle du réseau mobile (par exemple Wi-Fi, LAN ou une zone personnalisée configurée), le réseau d’appareils mobiles comme Source networks and devices, WAN comme Destination zone et le groupe Google comme Destination networks. Elle se situe en dessous de l’exclusion par défaut fixe mais au-dessus de la règle générale de décryptage. Gardez le réseau mobile isolé des ressources internes sensibles.

Validez la configuration à l’aide d’un appareil pilote Android : vérifiez la connectivité et l’accès via le navigateur, téléchargez une application de test approuvée depuis Google Play et mettez à jour une application installée via Google Play. Chaque opération doit se terminer avec succès. Dans Log viewer, seules les destinations Google attendues doivent correspondre à l’exception ; une autre destination HTTPS du même VLAN doit toujours utiliser la règle de décryptage prévue. Confirmez la zone source et l’objet source réels, la correspondance avec l’exception Google et la correspondance avec la règle de décryptage prévue pour ces flux réels. Utilisez un appareil pilote géré dont le navigateur ou l’application de test spécifique fait confiance à l’autorité de certification d’inspection ; vérifiez le bon fonctionnement et les preuves fournies par le certificat et les journaux pour la destination décryptée. Maintenez les clients ou applications dont la confiance envers l’autorité de certification d’inspection ne peut pas être gérée hors de la portée de Decrypt. Ce test négatif empêche l’acceptation d’une exception qui fonctionne mais qui est trop large. Créez des exceptions Web et des exclusions TLS en toute sécurité couvre d’autres méthodes et limitations SNI.

Vérifier l’efficacité

Une simulation de politique, un client réel et les journaux répondent à différentes questions. Combinez-les pour un test d’acceptation fiable.

Sous Diagnostics > Tools > Pop-out tools > Policy tester, sélectionnez Firewall, SSL/TLS, and web et définissez l’adresse IP source, la destination ou l’URL, le protocole et, si nécessaire, le port. Sans protocole, l’outil teste HTTP à l’aide du port par défaut spécifique au protocole. Le testeur de politiques simule un trafic Web transparent ; il ne modélise pas les routes SD-WAN et les règles avec les adresses MAC sous Source networks and devices n’y correspondent pas. Web policy only teste uniquement la stratégie Web. Le résultat est donc une prédiction et non une preuve du chemin réel des données.

Exécutez quatre tests ciblés sur le client :

1. Avant le changement, enregistrez le domaine de destination, l’émetteur du certificat, le temps de réponse et si l’application métier fonctionne.
2. Ouvrez une destination positive approuvée et vérifiez le parcours d’inspection choisi. Pour DPI, le navigateur doit afficher l’autorité de certification de re-signature sélectionnée pour DPI en tant qu’émetteur, et le Log viewer doit montrer une correspondance avec la règle de décryptage et le profil de décryptage attendus. Pour Web Proxy, vérifiez l’autorité de certification sélectionnée sous Web > General settings > HTTPS scanning certificate authority (CA), la règle de pare-feu qui correspond réellement avec Use web proxy instead of DPI engine et Decrypt HTTPS during web proxy filtering, ainsi que les preuves correspondantes du succès de la requête dans les journaux proxy/Web. N’exigez pas de correspondance avec une règle ou un profil DPI, ni d’entrée dans le widget DPI, pour une connexion décryptée par le proxy.
3. Ouvrez une destination délibérément exclue. Elle doit correspondre à la règle Don't decrypt attendue ; le navigateur ne doit pas y afficher un certificat re-signé par le pare-feu.
4. Une deuxième destination non exclue de la même étendue client doit encore être déchiffrée. C’est le test négatif de l’exception.

Si une politique Web fait partie de la conception, bloquez également une catégorie de test ou une URL de test spécifiquement approuvée à cet effet. Exécuter un test de malware uniquement avec un objet de test fournisseur documenté et inoffensif et un résultat attendu prédéfini. Avant et après le pilote, comparez la charge du processeur et de la mémoire, le temps de réponse et les erreurs utilisateur sur la même fenêtre temporelle.

Interpréter correctement Control Center et Log viewer

Le widget Control Center s’appelle SSL/TLS connections. Ses détails sont mis à jour toutes les cinq minutes. Les sessions couvrent les dernières 24 heures et les erreurs les derniers 7 jours ; Failed se réinitialise à minuit. Les données détaillées n’incluent pas les connexions au proxy Web. Decryption peak apparaît uniquement à proximité ou au-dessus du pic, et Decryption limit uniquement à proximité de la limite spécifique à l’appareil. Il n’existe donc pas de seuil universel pour tous les appareils.

Ouvrez le Log viewer en haut à droite et sélectionnez le module SSL/TLS inspection. Une connexion TLS est enregistrée une fois la négociation terminée et lors de sa fermeture. L’action, la règle, le profil de décryptage, la source, la destination, le domaine et la raison de l’erreur sont importants ; les couleurs ne constituent pas à elles seules un critère d’acceptation fiable. Sous Manage > Exclude, vous pouvez ajouter des domaines ou des sous-domaines à la liste d’exclusion TLS locale et des catégories à l’exclusion par défaut. Exclude n’est pas disponible pour les ID d’erreur 19004 et 19005.

Un événement Don't decrypt prouve uniquement que la connexion n’a pas été déchiffrée. Seuls la règle, la correspondance de liste et le test négatif indiquent si l’exception est justifiée et suffisamment étroite.

Circonscrire les erreurs et annuler les modifications

Lorsqu’un incident se produit, limitez initialement le cas à un client, un domaine, un moment précis, une règle de pare-feu et une règle d’inspection SSL/TLS.

• Si le navigateur affiche un avertissement de certificat, comparez l’émetteur visible avec l’autorité de certification utilisée par le chemin DPI ou proxy réel. Vérifiez ensuite le magasin de confiance du client, la chaîne racine/subordonnée et le nom d’hôte.
• Si des événements SSL/TLS sont manquants, vérifiez d’abord la correspondance de la règle du pare-feu et le mode. Confirmez ensuite que Rules and policies > SSL/TLS inspection rules et Advanced settings > SSL/TLS engine > Enabled sont actifs.
• Si le trafic est autorisé mais pas déchiffré, recherchez de haut en bas l’exclusion par défaut fixe, la liste gérée/locale ou une règle Don't decrypt personnalisée. Répétez ensuite le test négatif.
• Si le filtre Web ne s’applique pas, vérifiez la règle de pare-feu actuelle pour sa politique Web, Scan HTTP and decrypted HTTPS, Block QUIC protocol et le mode DPI/proxy. La présence d’une Web Policy ne prouve pas le décryptage.
• Si une seule application échoue, utilisez la raison de l’erreur, la version TLS, le chiffrement, la chaîne de certificat et l’épinglage pour guider la décision suivante. Limitez toute exception temporaire et attribuez-lui une date de révision.
• Si la charge augmente, réduisez la portée du pilote et comparez la même fenêtre temporelle avant et après le changement. Évaluez les avis de pointe ou de limite pour l’appareil spécifique.

Désactivez le SSL/TLS engine seulement brièvement pour le dépannage. Lorsqu’il est désactivé, aucune règle d’inspection SSL/TLS ne s’applique et le moteur DPI n’applique pas la politique Web du pare-feu au HTTPS ; le déchiffrement HTTPS du proxy Web n’est pas affecté. Le désactiver n’est donc pas un substitut équivalent et à faible risque à la désactivation spécifique de la règle pilote.

Testez l’IPS indépendant du port uniquement avec un état initial connu

Par défaut, SFOS vérifie le trafic déchiffré par rapport aux signatures IPS sur chaque port TCP. Pour un faux positif reproductible, documentez l’ID de signature, la source, la destination, le port TCP, la règle de pare-feu, la règle d’inspection et la version SFOS. Préférez une exception de signature étroite avec Action: Allow packet dans la stratégie IPS actuellement utilisée ; Configurer et tester Sophos Firewall IPS décrit cette méthode.

Un symptôme possible d’un problème lié à l’inspection indépendante du port est la détection répétée de la même signature IPS sur le même site Web. La répétition seule ne prouve pas un faux positif. On vérifie la correspondance exacte de la Signature ID et de la destination dans les journaux, on contrôle le processus de travail légitime concerné et on évalue le risque avant d’approuver une exception de signature à portée étroite et réversible.

L’inspection plus approfondie des menaces potentielles peut augmenter la charge et réduire légèrement le débit du trafic HTTPS déchiffré par rapport aux anciennes versions de Sophos Firewall. Il s’agit d’un effet possible lié à la version, et non d’une baisse garantie ni d’une preuve de régression du build actuellement utilisé. Pour contextualiser les résultats, on compare le débit, la charge CPU et mémoire ainsi que le temps de réponse avec une charge de trafic comparable dans la même fenêtre temporelle ; une seule comparaison ne remplace pas une analyse des causes.

Une comparaison globale dans la console de l’appareil n’est autorisée que si la valeur actuelle exacte, on ou off, est déjà connue à partir de l’enregistrement des modifications ou d’une configuration sauvegardée de manière fiable. La documentation officielle du SFOS 22 ne donne aucune vérification préalable en lecture seule pour ce commutateur. Si l’état initial est inconnu, n’effectuez pas le test.

Ce n’est qu’avec un état initial documenté de on que vous pouvez définir les éléments suivants pour une comparaison préparée :

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

La deuxième commande ici restaure uniquement l’état initial connu de on. Si l’état initial était off, ne l’activez pas aveuglément ; conservez off ou restaurez-le exactement après toute modification autorisée. Ce paramètre global affecte l’ensemble du pare-feu et peut réduire légèrement le débit ou, avec off, restreindre la portée de l’inspection. Documentez le résultat et la fenêtre de temps sans considérer cela seul comme la preuve d’une cause générale.

Effectuer le rollback dans un ordre défini

Un rollback restaure l’état initial documenté plutôt que d’introduire une nouvelle architecture :

1. Avant de désactiver TLS decrypt pilot client, vérifiez la règle suivante consignée et le plan de restauration approuvé : une règle Decrypt plus générale située plus bas peut prendre le relais. Désactivez la règle pilote et restaurez les modifications documentées propres au pilote concernant les règles de pare-feu, le mode DPI/proxy, la politique Web et les paramètres globaux dans l’ordre préparé, sans effectuer simultanément de modifications sans rapport.
2. Établissez de nouvelles connexions depuis le client pilote et vérifiez le parcours initial de correspondance consigné, l’émetteur du certificat, les journaux et le fonctionnement de l’application. Ne présumez pas que les sessions existantes sont immédiatement réévaluées. Si une règle Decrypt située plus bas prend le relais ou si la restauration échoue, arrêtez le nettoyage : le retour à l’état initial n’est pas terminé. Identifiez la règle qui correspond réellement et restaurez uniquement l’ordre des règles, les critères et les paramètres autorisés nécessaires pour reproduire l’état initial, puis répétez ces vérifications avec de nouvelles connexions.
3. Uniquement si le parcours initial n’était pas décrypté et si le plan de rétablissement approuvé l’exige, utilisez une règle Don't decrypt limitée dans le temps et à portée étroite pour la source pilote et les destinations requises, placée avant la règle Decrypt située plus bas qui correspond de manière non prévue, mais en dessous des exclusions approuvées applicables. Exécutez ses tests positif et négatif ; n’improvisez pas un contournement large et ne remplacez pas un parcours précédemment vérifié par un parcours non vérifié.
4. Supprimez les exceptions temporaires, les objets de test et la confiance envers l’autorité de certification ainsi que les paramètres CA propres au pilote uniquement après vérification de la restauration et approbation de la suppression. Conservez la confiance envers les autorités de certification encore requises par le parcours actif jusqu’à la réussite de ces vérifications ; ne supprimez pas les autorités de certification partagées sans vérifier les dépendances.
5. Enregistrez l’ID de règle, le client, la destination, l’autorité de certification visible, l’événement de journal, l’heure et les paramètres restaurés dans l’enregistrement des modifications.

La stratégie Web peut rester configurée, mais sans décryptage, elle ne peut pas analyser la charge utile HTTPS chiffrée. Revenir au proxy Web uniquement s’il s’agit de l’état initial vérifié. Ne désactivez pas l’intégralité du moteur SSL/TLS en tant que restauration standard, car cela arrête toutes les règles DPI TLS et l’application de la politique Web DPI à HTTPS.

Arrêtez le déploiement dès qu’une application critique pour l’entreprise tombe en panne, que des avertissements de certificat apparaissent en dehors du groupe pilote, que la portée correspond plus largement que prévu ou que la charge et les erreurs dépassent les limites prédéfinies. Développez le groupe Source progressivement seulement après que le test positif, le test négatif d’exception, les applications métier, les journaux, les commentaires des utilisateurs et le profil de charge répondent tous aux critères convenus tout au long de la période convenue.

Pendant le fonctionnement, examinez les exclusions, les erreurs TLS, les nouvelles applications, la charge et les commentaires des utilisateurs selon un calendrier défini. Conservez les exceptions temporaires uniquement pendant que le propriétaire, le motif et la date de révision restent valides ; sinon, retirez-les après un nouveau test positif et négatif.

FAQ