Le trafic Web chiffré par TLS (Transport Layer Security) représente une grande partie de l'ensemble du trafic Web, et les acteurs malveillants peuvent utiliser ces canaux chiffrés pour lancer des attaques malveillantes. Par conséquent, il est essentiel de vérifier le trafic chiffré TLS avant de le transférer vers sa destination.
Le proxy Web sécurisé offre un service d'inspection TLS qui vous permet d'intercepter le trafic TLS, d'inspecter la requête chiffrée et d'appliquer des règles de sécurité.
En fonction des règles de sécurité mises en œuvre et de la configuration de l'inspection TLS, la solution de proxy Web sécurisé établit deux connexions sécurisées, l'une avec le client et l'autre avec le serveur externe. La solution proxy Web sécurisé inspecte ensuite le trafic entre les deux connexions sécurisées. Une fois la validation effectuée, vous pouvez appliquer au trafic chiffré les mêmes contrôles de filtrage et de sécurité que le trafic non chiffré.
Rôle des autorités de certification dans l'inspection TLS
Pour déterminer si le proxy Web sécurisé doit inspecter une connexion TLS, il vérifie l'option tls_inspection_enabled sur ses règles de stratégie de sécurité individuelles. Si l'indicateur est défini et qu'une connexion TLS est détectée, le proxy Web sécurisé génère un nouveau certificat de serveur. Il envoie ce certificat au Certificate Authority Service (CAS) pour qu'il le signe par votre pool d'autorités de certification subordonné.
Ce certificat est ensuite présenté au client, et une connexion TLS est établie. Le certificat généré est mis en cache pendant une courte période pour être utilisé lors de connexions ultérieures au même hôte.
Si vous souhaitez inspecter le trafic TLS, vous devez générer un certificat de serveur pour l'hôte auquel le client tente de se connecter. Une autorité de certification privée gérée par l'organisation doit signer ce certificat de serveur. Seuls les clients configurés pour approuver cette autorité de certification privée font confiance à ces certificats de serveur générés. Ceux-ci incluent les navigateurs et les clients HTTP intégrés. Par conséquent, l'inspection TLS ne peut être utilisée que pour intercepter et inspecter les connexions TLS des clients sur lesquels votre organisation exerce un contrôle administratif.
Toutes les connexions TLS ne peuvent pas être interceptées, même sur des machines sur lesquelles l'organisation exerce un contrôle administratif. En effet, certains clients (en particulier ceux intégrés à d'autres applications) sont codés en dur pour n'accepter que des certificats de serveur spécifiques ou ceux signés par des autorités de certification spécifiques (pratique appelée épinglage de certificats). Les mises à jour logicielles Microsoft Windows, MacOS et Google Chrome en sont quelques exemples. En présence de l'inspection TLS, ces connexions échouent. En effet, la clé publique et la chaîne d'autorité de certification du certificat de serveur que le proxy Web sécurisé présente au client ne correspondent pas aux paramètres stockés localement.
Si une règle est configurée pour inspecter le trafic TLS, mais que le client ne fait pas confiance aux certificats d'inspection présentés par le proxy Web sécurisé, la connexion échoue. Dans ce cas, l'inspection TLS est connue pour rompre les connexions client-serveur, même si le serveur est approuvé. Pour contourner cette situation, vous pouvez ajouter des règles permettant de contourner l'inspection TLS pour des critères spécifiques. Vous pouvez également limiter l'inspection TLS à des hôtes de destination spécifiques (en utilisant le nom de domaine complet), à des sources (à l'aide de tags sécurisés, d'un compte de service ou d'une adresse IP) et en utilisant l'attribut SessionMatcher d'une règle.
Fonctionnalités compatibles
L'inspection TLS du proxy Web sécurisé est compatible avec les fonctionnalités suivantes:
- Intégration étroite à CAS, un dépôt hautement disponible et évolutif pour les autorités de certification privées.
- La possibilité d'utiliser votre propre racine de confiance si nécessaire Vous pouvez également utiliser une autorité de certification racine existante pour signer les autorités de certification subordonnées par des CAS. Si vous préférez, vous pouvez générer un nouveau certificat racine au sein de CAS.
- Critères de déchiffrement précis en utilisant
SessionMatcherdans les règles de stratégie de proxy Web sécurisé. Ces critères incluent les hôtes correspondants présents dans les listes d'URL, les expressions régulières, les plages d'adresses IP et les expressions similaires. Si nécessaire, les critères peuvent être combinés à des expressions booléennes. - Chaque règle de proxy Web sécurisé peut être configurée avec sa propre règle d'inspection TLS et son propre pool d'autorités de certification. Par ailleurs, plusieurs règles de proxy Web sécurisé peuvent partager une même règle d'inspection TLS.
Cas d'utilisation courants
Pour activer l'inspection TLS, vous pouvez utiliser l'une des méthodes suivantes:
Utilisez une autorité de certification racine existante pour signer les CA subordonnées au sein d'un CAS. Une autorité de certification subordonnée détenue au sein d'un CAS permet de signer les certificats de serveur générés au moment de l'exécution.
Utilisez une autorité de certification racine existante détenue en externe (et non dans un CAS) pour signer des autorités de certification subordonnées. Lorsque les autorités de certification subordonnées sont signées par votre autorité de certification racine, vous pouvez les utiliser pour signer les certificats de serveur générés au moment de l'exécution.
Utilisez un certificat racine généré au sein d'autorités de certification. Après avoir créé le certificat racine, vous créez une autorité de certification subordonnée signée par votre nouvelle autorité de certification racine. Cette autorité de certification subordonnée permet de signer les certificats de serveur générés au moment de l'exécution.
Pour en savoir plus sur ces méthodes, consultez la section Créer un pool d'autorités de certification subordonné.