Une fois l'interception TLS activée et un certificat d'autorité de certification (CA) privée configuré pour une instance, Egress Proxy Gateway (EPG) peut déchiffrer le trafic HTTPS sortant et inspecter son contenu. Cette fonctionnalité vous permet d'auditer le trafic chiffré et d'appliquer un contrôle granulaire, contribuant ainsi à répondre aux exigences de sécurité telles que la prévention des fuites de données et la conformité aux normes de protection classifiée.
Fonctionnement
Lorsque l'interception TLS est activée, EPG agit en tant que proxy et établit une connexion TLS distincte avec le client d'une part, et avec le serveur de destination d'autre part. Le processus se déroule comme suit :
Le client envoie une requête HTTPS à EPG. EPG utilise le certificat de CA privée configuré pour émettre dynamiquement un certificat de serveur correspondant au nom de domaine de destination, et finalise la négociation TLS avec le client à l'aide de ce certificat.
EPG déchiffre la requête pour obtenir du texte HTTP en clair et applique les règles durant la phase PreRequest, en se basant sur des éléments tels que le chemin URI, la méthode de requête et les en-têtes de requête.
Lorsque la requête satisfait aux règles, EPG établit une connexion TLS avec le serveur de destination, chiffre la requête et la transfère.
Après avoir reçu la réponse chiffrée du serveur de destination, EPG la déchiffre, la rechiffre via la connexion TLS établie avec le client, puis la renvoie au client.
Étant donné qu'EPG doit maintenir simultanément deux connexions TLS (une avec le client et une avec le serveur de destination) et procéder au déchiffrement ainsi qu'au rechiffrement du trafic, l'activation de l'interception TLS introduit une certaine latence de transfert.
L'interception TLS et l'accès client TLS sont deux concepts indépendants. Veillez à ne pas les confondre.
Interception TLS : détermine si EPG déchiffre le trafic HTTPS entre le client et le serveur de destination. Une fois activée, EPG agit comme un proxy, utilise le certificat de CA privée configuré pour émettre dynamiquement un certificat de serveur et complète la négociation TLS avec le client. Ainsi, le trafic est déchiffré en texte clair, permettant le contrôle et l'audit du contenu de la couche 7.
Accès client TLS : détermine si la communication entre le client et EPG est chiffrée. Cette fonctionnalité utilise le port d'écoute HTTPS de l'instance EPG (par exemple, le port 443) pour sécuriser le canal de proxy lui-même, ce qui est généralement utilisé dans les scénarios zero trust.
Si l'interception TLS est désactivée pour une instance, le client utilise la méthode CONNECT pour établir un tunnel chiffré de bout en bout avec le serveur de destination via EPG pour les requêtes HTTPS. EPG se contente de transférer le trafic et ne peut pas analyser le contenu de la requête à l'intérieur du tunnel. Dans ce cas, les requêtes HTTPS n'entrent pas dans la phase PreRequest, et ni les règles ni l'action par défaut de cette phase ne s'appliquent. Les requêtes sont transférées directement via le pool d'adresses par défaut. Pour contrôler le trafic HTTPS, activez l'interception TLS. Si vous souhaitez contrôler le trafic uniquement par adresse IP source ou nom de domaine de destination, configurez des règles dans la phase PreDns.
Prérequis
Vous avez créé une instance EPG.
Vous avez créé une instance ECS exécutant Alibaba Cloud Linux et prenant en charge les connexions Secure Shell (SSH) dans le VPC où réside l'instance EPG.
Procédure
1. Activer l'interception TLS
Vous pouvez activer l'interception TLS lors de la création d'une instance ou après sa création. Cette rubrique présente un exemple d'activation de l'interception TLS après la création de l'instance.
Sur la page Instances de la console EPG, cliquez sur l'ID de l'instance cible pour accéder à sa page de détails.
Sous l'onglet Listener configuration, cliquez sur Edit à droite de TLS interception configuration.
Dans la boîte de dialogue Edit the TLS interception configuration., sélectionnez TLS interception configuration, puis choisissez la CA privée utilisée pour le déchiffrement dans la liste déroulante Certificate ID. Si aucun certificat n'est disponible, cliquez sur Create Certificate pour accéder à la console de gestion des certificats PCA et en créer un (une CA privée est une ressource payante). Une fois la configuration terminée, cliquez sur Save.
L'interception TLS prend en charge les CA privées utilisant l'algorithme RSA ou ECC. Les CA racines et les CA subordonnées sont toutes deux prises en charge. Nous vous recommandons d'utiliser une CA subordonnée afin de réduire la fréquence d'utilisation et les risques d'exposition de la clé privée de la CA racine.
Assurez-vous que le certificat de CA privée utilisé pour l'interception TLS est valide. Renouvelez le certificat ou remplacez-le par un autre certificat valide avant son expiration. Sinon, l'interception TLS risque de ne pas fonctionner correctement.
Pour désactiver l'interception TLS, décochez TLS interception configuration au même emplacement, puis cliquez sur Save . Une fois l'interception TLS désactivée, le champ TLS interception mode affiche la valeur Not enabled .
2. Configurer le client pour qu'il approuve le certificat de CA privée
Une fois l'interception TLS activée, EPG utilise le certificat de CA privée pour émettre dynamiquement des certificats pour les noms de domaine de destination. Le client doit approuver le certificat de CA privée. Sinon, l'avertissement de certificat SSL certificate problem s'affiche.
Dans la console de gestion des certificats PCA, localisez la CA privée utilisée pour l'interception TLS. Dans la colonne Actions, choisissez
> Details. Copiez les Certificate Information (au format PEM, de -----BEGIN CERTIFICATE-----à-----END CERTIFICATE-----).-
Enregistrez le contenu du certificat sur l'instance ECS. Exemple :
/tmp/epg-ca.pem.sudo tee /tmp/epg-ca.pem > /dev/null <<'EOF' (Paste the certificate content, from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE-----) EOF -
Installez le certificat dans le magasin de confiance du système.
# Alibaba Cloud Linux / CentOS sudo cp /tmp/epg-ca.pem /etc/pki/ca-trust/source/anchors/epg-ca.crt sudo update-ca-trust extract # Ubuntu / Debian sudo cp /tmp/epg-ca.pem /usr/local/share/ca-certificates/epg-ca.crt sudo update-ca-certificates
Certaines applications ou langages de programmation, tels que Java, Node.js et certaines bibliothèques Python, utilisent leurs propres magasins de certificats de confiance plutôt que celui du système. Si l'avertissement persiste après l'importation du certificat dans le magasin de confiance du système, importez le certificat de CA privée dans le magasin de confiance de l'environnement d'exécution concerné, selon les besoins.
3. Vérifier que l'interception TLS est effective
Avant de vérifier, configurez les variables d'environnement du proxy. Si elles ne sont pas configurées, consultez la rubrique Configurer l'accès via un proxy HTTP/HTTPS pour finaliser la configuration de l'accès par proxy. Sur l'instance ECS, accédez à un site HTTPS via le proxy et vérifiez si l'émetteur du certificat de serveur correspond à la CA privée utilisée par EPG :
curl -v --max-time 15 https://www.example.com 2>&1 | grep "issuer"Si l'émetteur affiché correspond au nom de la CA privée utilisée par EPG, l'interception TLS est effective. Cela indique qu'EPG a réémis le certificat à l'aide de votre CA privée et a réussi à déchiffrer le trafic.
Pour vérifier plus approfondément si les règles de la phase PreRequest phase s'appliquent aux requêtes HTTPS après déchiffrement, commencez par configurer des règles et associer le groupe de règles à la configuration du proxy de sortie. Ensuite, envoyez une requête et observez le résultat.