Traitement des requêtes CONNECT

Lors du traitement du trafic transmis via le protocole HTTPS, le résultat de l'application des actions de l'application Interdire et Rediriger diffère de l'application de ces actions au trafic transmis via le protocole HTTP. L'utilisateur voit s'afficher la page de blocage et il est redirigé vers l'adresse URL spécifiée. Au lieu de cela, la connexion est interrompue.

Ceci est dû au fait que pour établir des connexions chiffrées via le protocole HTTPS, l'ordinateur de l'utilisateur demande une connexion du serveur proxy au serveur Internet à l'aide d'un message HTTP contenant la méthode CONNECT (également dénommée ici « requête CONNECT »). Les possibilités de traitement des requêtes CONNECT et de réponse à celles-ci par les serveurs proxy sont limitées au niveau du protocole HTTP. Le serveur proxy peut soit avertir l'utilisateur d'une connexion réussie, soit mettre fin à la connexion.

Pour que les actions Interdire et Rediriger soient appliquées correctement, vous devez activer le déchiffrement des connexions TLS/SSL et ajouter la méthode CONNECT aux exclusions ou lui créer une règle de contournement. S'il n'y a pas de règles de traitement du trafic autorisant les requêtes CONNECT, la connexion sera interrompue.

L'activation des requêtes CONNECT peut réduire la sécurité de l'infrastructure informatique de l'organisation. Il est recommandé d'ajouter la méthode CONNECT aux exclusions uniquement dans les règles de traitement du trafic pour lesquelles il est essentiel d'afficher la page de blocage et procéder à une redirection.

Plus loin, cet article présente les particularités et les différences dans le traitement du trafic transmis via le protocole HTTP à l'aide de messages HTTP standard et du trafic transmis via le protocole HTTPS lorsque des requêtes CONNECT sont utilisées pour établir des connexions chiffrées.

Traitement des messages HTTP standard

La plupart des méthodes HTTP (par exemple GET, POST, DELETE, HEAD, OPTIONS, PATCH, PUT, TRACE) sont conçues pour échanger des messages HTTP entre le client, c'est-à-dire l'ordinateur de l'utilisateur, et le serveur Internet sur lequel la ressource Internet demandée est stockée. Kaspersky Web Traffic Security peut analyser ce type de messages HTTP et leur appliquer toutes les actions disponibles dans l'application. L'illustration ci-dessous présente les principes de traitement des messages HTTP dans l'application Kaspersky Web Traffic Security.

Principes de traitement des messages HTTP

La numérotation sur l'illustration correspond aux étapes suivantes du traitement des messages HTTP standard :

1. L'utilisateur demande l'accès à la ressource Internet. Cette requête est transmise au serveur proxy.
2. L'application vérifie si la ressource Internet demandée répond aux critères des règles d'accès.
3. Si l'action Interdire est exécutée suite à l'application d'une règle d'accès, une page de blocage s'affiche sur le système de l'utilisateur. Si l'action Rediriger est exécutée, l'utilisateur est redirigé vers l'URL indiquée.
4. Si l'action Autoriser est exécutée suite à l'application d'une règle d'accès, l'application procède à l'analyse du trafic en utilisant les règles de protection ou la stratégie de protection par défaut. Si aucune menace n'est détectée, la requête de l'utilisateur est envoyée au serveur Internet.
5. La réponse du serveur Internet est également vérifiée par les modules de protection contre les virus et les autres menaces. Lors de la détection de menaces, l'application bloque le trafic, et en cas d'absence de menaces, il transmet la réponse du serveur Internet à l'ordinateur de l'utilisateur.
6. Comme le trafic est transmis sous une forme non chiffrée, des individus malintentionnés peuvent intercepter des données en tentant d'obtenir un accès non autorisé.

Particularités du traitement des requêtes CONNECT

Si quelqu'un tente d'accéder à une ressource Internet via le protocole HTTPS, l'ordinateur de l'utilisateur envoie une requête CONNECT au serveur proxy pour se connecter au serveur Internet. L'échange de paramètres de chiffrement et de certificats de sécurité entre l'ordinateur de l'utilisateur et le serveur Internet est suivi par l'établissement d'une connexion sécurisée par tunnel via le protocole TLS. Dans ce tunnel, le client et le serveur Internet échangent des messages HTTPS en utilisant des méthodes HTTP standard (GET, POST, etc.). Par défaut, le serveur proxy ne peut pas analyser le contenu de la connexion chiffrée et interférer avec l'échange de messages dans le tunnel. L'illustration ci-dessous présente le mécanisme de traitement des connexions chiffrées par défaut.

Mécanisme de traitement des connexions chiffrées par défaut

La numérotation sur l'illustration correspond aux étapes suivantes du traitement des connexions chiffrées par défaut :

1. L'ordinateur de l'utilisateur utilise une requête CONNECT pour demander au serveur proxy de lui fournir un canal de communication chiffré avec le serveur Internet.
2. L'application vérifie si la ressource Internet demandée répond aux critères des règles d'accès.
3. Si l'action Interdire ou Rediriger est exécutée suite à l'application des règles, la connexion est interrompue. L'utilisateur voit s'afficher la page de blocage et il n'est pas redirigé vers l'adresse URL spécifiée.
4. Si l'action Autoriser est exécutée suite à l'application d'une règle d'accès, l'application envoie une requête CONNECT pour un traitement ultérieur par les modules de protection.
5. Si la requête CONNECT est analysée avec succès par les modules de protection, le serveur proxy forme un canal de communication chiffré entre l'ordinateur de l'utilisateur et le serveur Internet.
6. L'ordinateur de l'utilisateur échange des messages HTTP ordinaires avec le serveur Internet à l'intérieur du canal de communication chiffré. Cependant, le serveur proxy ne peut pas accéder à ces messages et les transmettre aux modules de protection pour analyse, car les données transmises sont chiffrées.
7. La réponse du serveur Internet est également transmise directement à l'ordinateur de l'utilisateur sans être analysée par les modules de protection. Cela réduit le niveau de protection de l'infrastructure informatique de l'organisation, car l'ordinateur de l'utilisateur peut recevoir du trafic comportant des menaces.
8. Comme le trafic est transmis à l'intérieur d'un canal chiffré, des individus malintentionnés ne peuvent pas intercepter des données en tentant d'obtenir un accès non autorisé.

Pour que l'application puisse, avec les modules de protection, analyser le trafic transmis à l'intérieur du canal de communication chiffré, vous devez configurer le déchiffrement des connexions TLS/SSL. L'illustration ci-dessous présente le mécanisme de traitement des connexions chiffrées lorsque le déchiffrement des connexions TLS/SSL est activé.

Mécanisme de traitement des connexions chiffrées lorsque le déchiffrement des connexions TLS/SSL est activé

La numérotation sur l'illustration correspond aux étapes suivantes du traitement des connexions chiffrées lorsque le déchiffrement des connexions TLS/SSL est activé :

1. L'ordinateur de l'utilisateur utilise une requête CONNECT pour demander au serveur proxy de lui fournir un canal de communication chiffré avec le serveur Internet.
2. L'application vérifie si la ressource Internet demandée répond aux critères des règles d'accès.
3. Si l'action Interdire ou Rediriger est exécutée suite à l'application d'une règle d'accès, la connexion est interrompue. L'utilisateur voit s'afficher la page de blocage et il n'est pas redirigé vers l'adresse URL spécifiée.
4. Si l'action Autoriser est exécutée suite à l'application d'une règle d'accès, l'application envoie une requête CONNECT pour un traitement ultérieur par les modules de protection.
5. Des canaux de communication chiffrés sont installés si la requête CONNECT est analysée avec succès par les modules de protection entre l'ordinateur de l'utilisateur et le serveur proxy, ainsi qu'entre le serveur proxy et le serveur Internet.
6. Dans le canal de communication chiffré, l'ordinateur de l'utilisateur échange des requêtes HTTP ordinaires avec le serveur Internet. L'application a accès à toutes les données transmises et peut lui appliquer des règles de protection.
7. L'application vérifie si la ressource Internet demandée répond aux critères des règles d'accès.
8. Si l'action Interdire est exécutée suite à l'application d'une règle d'accès, une page de blocage s'affiche sur le système de l'utilisateur. Si l'action Rediriger est exécutée, l'utilisateur est redirigé vers l'URL indiquée.
9. Si l'action Autoriser est exécutée suite à l'application d'une règle d'accès, l'application procède à l'analyse du trafic en utilisant les règles de protection ou la stratégie de protection par défaut. Si aucune menace n'est détectée, la requête de l'utilisateur est envoyée au serveur Internet.
10. La réponse du serveur Internet est également vérifiée par les modules de protection contre les virus et les autres menaces. Lors de la détection de menaces, l'application bloque le trafic, et, en cas d'absence de menaces, il transmet la réponse du serveur Internet à l'ordinateur de l'utilisateur via le canal de communication chiffré.
11. Comme le trafic est transmis à l'intérieur d'un canal de communication chiffré, des individus malintentionnés ne peuvent pas intercepter des données en tentant d'obtenir un accès non autorisé.