À propos des connexions TLS

Lorsqu'un utilisateur souhaite se connecter à une ressource Internet via le protocole HTTPS, une connexion chiffrée sécurisée doit être établie entre l'ordinateur de l'utilisateur et le serveur Internet sur lequel la ressource Internet requise est stockée. Une fois la connexion TCP/IP de base établie, le client et le serveur échangent les certificats de sécurité et les paramètres de chiffrement. Ensuite, un canal de communication chiffré est créé à l'aide du protocole TLS (Transport Layer Security). Par conséquent, les connexions chiffrées sont également appelées connexions TLS. A l'intérieur de ce canal, les données sont transmises via un protocole de niveau appliqué, par exemple HTTP.

Si le déchiffrement des connexions TLS/SSL est désactivé dans l'application, le serveur proxy envoie des messages entre le client et le serveur sans intervenir dans le processus d'établissement d'une connexion chiffrée. Dans ce cas, les modules de protection Kaspersky Web Traffic Security (Antivirus et Antiphishing) ne peuvent pas analyser les données transmises à l'intérieur du canal de communication chiffré. Cela réduit le niveau de protection de l'infrastructure informatique de l'organisation. Il est donc recommandé d'activer le déchiffrement des connexions TLS/SSL.

Lorsque vous activez le déchiffrement des connexions TLS/SSL dans les paramètres de l'application, le serveur proxy peut interférer dans le processus d'établissement de la connexion. Dans ce cas, l'application peut appliquer au trafic les actions spécifiées dans les règles SSL ou les actions par défaut si le trafic analysé ne remplit les conditions d'aucune des règles SSL.

L'application prévoit les actions suivantes pour le traitement des connexions chiffrées :

Tunnel.
Tunnel with SNI check.
Bump.
Terminate.

Il est recommandé de sélectionner l'action Bump pour assurer le niveau de protection maximum. Il est recommandé d'utiliser les actions Tunnel et Tunnel with SNI check uniquement pour les ressources Internet et les applications qui ne prennent pas en charge une utilisation lors du déchiffrement du trafic transmis (par exemple, les applications bancaires).

Application des actions Tunnel, Tunnel with SNI check ou Terminate

L'illustration ci-dessous présente les principes d'établissement de connexions chiffrées lors de l'application des actions Tunnel, Tunnel with SNI check ou Terminate.

kwts_tls_without bumping

Principes d'établissement de connexions chiffrées lors de l'application des actions Tunnel, Tunnel with SNI check ou Terminate

L'établissement d'une connexion chiffrée comprend les étapes suivantes :

Requête du client
Le client envoie une requête CONNECT au serveur proxy pour se connecter au serveur Internet. Cette requête contient le nom de domaine complet (FQDN) ou l'adresse IP du serveur Internet sur lequel se trouve la ressource Internet demandée.
Transmission de la requête au serveur
Le serveur proxy génère et envoie une demande de connexion au serveur Internet, reçoit une réponse de celui-ci et transmet cette réponse au client.
Transmission du SNI et des autres paramètres de chiffrement du client au serveur proxy
Le client transmet, au serveur proxy, un ensemble de paramètres de chiffrement pris en charge ainsi que le champ SNI, dans lequel est indiqué le nom de domaine complet (FQDN) de la ressource Internet (site Internet) requise.

Extension du protocole TLS, transmettant le nom du site Internet auquel la connexion doit être établie. Le SNI est nécessaire dans les cas où plusieurs services travaillant sur le protocole HTTPS sont situés sur un serveur physique et utilisent une seule adresse IP, mais où chaque service possède son propre certificat de sécurité.
Vérification de la nécessité d'interruption de la connexion
Si l'action Terminate est appliquée à une requête selon les actions indiquées dans les règles SSL ou l'action par défaut, la connexion est interrompue. La page de blocage ne s'affiche pas sur le système de l'utilisateur.
Transmission du SNI et des autres paramètres de chiffrement du client au serveur Internet
Si l'action Terminate n'a pas été appliquée à la requête, le serveur proxy transmet, au serveur Internet, le champ SNI et les autres paramètres de chiffrement au nom du client.
Transmission du certificat de la ressource Internet au serveur proxy
Le serveur Internet renvoie au serveur proxy l'ensemble des paramètres de chiffrement pris en charge ainsi que le certificat de la ressource Internet à laquelle l'utilisateur a demandé l'accès, en fonction du champ SNI.
Transmission du certificat de la ressource Internet au client
Le serveur proxy transmet au client le certificat et les paramètres de chiffrement reçus de la part du serveur Internet.
Établissement d'une connexion sécurisée
Le client et le serveur décident des autres détails de la connexion. Ensuite, un canal de communication sécurisé est créé, à l'intérieur duquel le client et le serveur peuvent échanger des données.

Application des actions Terminate et Bump

L'illustration ci-dessous présente les principes de traitement des connexions chiffrées lors de l'application des actions Terminate et Bump. Dans ce cas, les étapes 5 et 7 diffèrent de la disposition de base de l'établissement d'une connexion chiffrée. À l'étape 5, le serveur proxy transmet le champ SNI et les autres paramètres de chiffrement non pas au nom du client, mais pour son propre compte. Le serveur proxy reçoit, de la part du serveur Internet, le certificat de la ressource Internet demandée, génère son propre certificat (de remplacement) à partir de celui-ci et transmet ce certificat de remplacement au client.

kwts_tls_with_bumping

Principes de traitement des connexions chiffrées lors de l'application des actions Terminate et Bump

Les différences dans le processus de traitement de la connexion chiffrée par l'application sont indiquées dans le tableau ci-dessous en fonction de l'action spécifiée.

Traitement des connexions chiffrées par l'application en fonction de l'action spécifiée

Sans serveur proxy	Tunnel	Tunnel with SNI check	Bump	Terminate
Requête du client.	Requête du client. Le serveur proxy permet de créer un canal sécurisé basé sur l'adresse IP ou le nom de domaine complet (FQDN) du serveur Internet.	Requête du client.	Requête du client.	Requête du client.
Réponse du serveur.	Réponse du serveur.	Réponse du serveur.	Réponse du serveur.	Réponse du serveur.
Transmission du SNI et des autres paramètres de chiffrement du client.	Transmission du SNI et des autres paramètres de chiffrement du client.	Transmission du SNI et des autres paramètres de chiffrement du client. Le serveur proxy permet de créer un canal sécurisé basé sur le SNI de la ressource Internet demandée.	Transmission du SNI et des autres paramètres de chiffrement du client. Le serveur proxy envoie ces données au serveur Internet, non pas au nom du client, mais en son propre nom.	La connexion est interrompue. La page de blocage ne s'affiche pas sur le système de l'utilisateur.
Transmission du certificat de la ressource Internet demandée.	Transmission du certificat de la ressource Internet demandée.	Transmission du certificat de la ressource Internet demandée.	Transmission du certificat de la ressource Internet demandée. Le serveur proxy intercepte le certificat envoyé par le serveur Internet et, à partir de celui-ci, génère son propre certificat de remplacement.	–
Établissement d'une connexion sécurisée.	Établissement d'une connexion sécurisée. L'application ne peut pas analyser les données transmises par les modules Antivirus et Anti-Phishing.	Établissement d'une connexion sécurisée. L'application ne peut pas analyser les données transmises par les modules Antivirus et Anti-Phishing.	Établissement d'une connexion sécurisée. Deux canaux sont créés : l'un entre le client et le serveur proxy, et l'autre entre le serveur proxy et le serveur Internet. L'application peut analyser le contenu des canaux protégés et appliquer des règles de traitement du trafic aux données transmises à l'intérieur du canal.	–

Haut de page