Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit le flux réseau dans le réseau configuré par proxy, en particulier sur l'appareil Web sécurisé (SWA).
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Les abréviations utilisées dans ces articles sont :
TCP : protocole de contrôle de transmission
UDP : protocole de datagramme utilisateur
IP : protocole Internet
GRE : encapsulation de routage générique
HTTP : Hypertext Transfer Protocol.
HTTPS : Protocole de transfert hypertexte sécurisé.
URL : Uniform Resource Locator
TLS : sécurité de la couche transport
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Une connexion TLS en HTTPS se produit lorsqu'un client et un serveur communiquent via Internet, fournissant ainsi une connexion sécurisée. Le processus assure la confidentialité et l'intégrité des données entre deux applications en communication. Il fonctionne selon une série d'étapes au cours desquelles le client et le serveur s'accordent sur les normes et les codes de cryptage pour toutes les transmissions ultérieures. La prise de contact vise à dissuader tout accès non autorisé ou toute manipulation par des tiers. Il authentifie également les identités des parties communicantes pour éliminer l'usurpation d'identité. Ce processus est essentiel dans HTTPS, car il garantit que les données restent sécurisées pendant leur transit.
Voici les étapes d'une prise de contact TLS :
Client Hello : le client lance le processus de connexion avec un message Hello. Ce message contient la version TLS du client, les suites de chiffrement prises en charge et une chaîne d'octets aléatoire appelée « client random ».
Server Hello : le serveur répond par un message Hello. Ce message inclut la version TLS choisie par le serveur, la suite de chiffrement sélectionnée, une chaîne d'octets aléatoire appelée « server random » et le certificat numérique du serveur. Si nécessaire, le serveur demande également le certificat numérique client pour une authentification mutuelle.
Le client vérifie le certificat du serveur : le client vérifie le certificat numérique du serveur auprès de l'autorité de certification qui l'a émis. Cela garantit au client qu'il communique avec le serveur légitime.
Pre-master Secret : le client envoie une chaîne d'octets aléatoire, connue sous le nom de « pre-master secret », qui contribue à la création des clés de session. Le client chiffre ce secret prémaître avec la clé publique du serveur, de sorte que seul le serveur peut le déchiffrer avec sa clé privée.
Secret maître : le client et le serveur utilisent le secret pré-maître et les chaînes d'octets aléatoires des messages Hello pour calculer indépendamment le même « secret maître ». Ce secret partagé est à la base de la génération des clés de session.
Client Finished : le client envoie un message « Finished », chiffré avec la clé de session, pour signaler la fin de la partie client de la connexion.
Server Finished : le serveur envoie un message « Finished », également chiffré avec la clé de session, pour signaler la fin de la partie serveur de la connexion.
Code | Détails |
100 Continuer |
Généralement vu en ce qui concerne le protocole ICAP. Il s'agit d'une réponse informative qui indique au client qu'il peut continuer à envoyer des données. En ce qui concerne les services ICAP (tels que l'analyse antivirus), le serveur ne peut afficher que la première x quantité d'octets. Lorsqu'il a terminé d'analyser le premier ensemble d'octets et qu'il n'a pas détecté de virus, il envoie un message 100 Continue pour informer le client qu'il doit envoyer le reste de l'objet. |
Code | Détails |
200 OK |
Code de réponse le plus courant. Cela signifie que la demande a abouti sans aucun problème. |
Code | Détails |
301 Redirection permanente |
Il s'agit d'une redirection permanente, vous pouvez voir ce code lorsque vous redirigez vers le sous-domaine www. |
302 Redirection temporaire |
Il s'agit d'une redirection temporaire. Le client est invité à effectuer une nouvelle requête pour l'objet spécifié dans l'en-tête Location : . |
304 Non modifié |
Ceci est en réponse à un GIMS (GET If-modified-Since). Il s'agit littéralement d'un HTTP GET standard qui inclut l'en-tête If-modified-Since: <date>. Cet en-tête indique au serveur que le client dispose d'une copie de l'objet demandé dans son cache local et qu'il inclut la date à laquelle l'objet a été récupéré. Si l'objet a été modifié depuis cette date, le serveur répond avec un 200 OK et une nouvelle copie de l'objet. Si l'objet n'a pas été modifié depuis la date d'extraction, le serveur renvoie une réponse 304 Not Modified. |
307 Redirection d'authentification |
Ceci est vu principalement, dans le déploiement de proxy transparent, quand le serveur proxy est configuré pour authentifier la demande et redirige la demande vers une autre URL pour authentifier l'utilisateur, |
Code | Détails |
400 Requête incorrecte |
Cela suggère un problème avec la requête HTTP, car elle n'est pas conforme à la syntaxe appropriée. Parmi les raisons possibles, citons plusieurs en-têtes sur une seule ligne, des espaces dans un en-tête ou l'absence de HTTP/1.1 dans l'URI, entre autres. Pour connaître la syntaxe correcte, consultez la RFC 2616. |
401 Non autorisé Authentification du serveur Web requise |
L'accès à l'objet demandé nécessite une authentification. Le code 401 est utilisé pour l'authentification avec un serveur Web cible. Lorsque le SWA fonctionne en mode transparent et que l'authentification est activée sur le proxy, il renvoie un 401 au client, puisque l'appliance se présente comme s'il s'agissait du serveur de contenu d'origine (OCS). Les méthodes d'authentification pouvant être utilisées sont détaillées dans un en-tête de réponse HTTP « www-authenticate: ». Indique au client si le serveur demande l'authentification NTLM, de base ou d'autres formes d'authentification. |
403 Refusé |
Le client ne peut pas accéder à l'objet demandé. Diverses raisons peuvent amener un serveur à refuser l'accès aux objets. Le serveur fournit généralement une description de cause dans les données HTTP ou la réponse HTML. |
404 Introuvable |
L'objet demandé n'existe pas sur le serveur. |
Authentification proxy 407 requise |
Il s'agit du même nom qu'un 401, à ceci près qu'il s'agit spécifiquement de l'authentification à un proxy et non à l'OCS. Ceci n'est envoyé que si la demande a été envoyée explicitement au proxy. Un 407 ne peut pas être envoyé à un client tant que SWA est configuré comme proxy transparent, car le client ne sait pas que le proxy existe. Si c'est le cas, le client est très probablement FIN ou RST sur le socket TCP. |
Code | Détails |
501 Erreur interne du serveur |
Échec du serveur Web générique. |
502 Passerelle incorrecte |
Se produit lorsqu'un serveur agissant en tant que passerelle ou proxy reçoit une réponse non valide d'un serveur entrant. Il signale que la passerelle a reçu une réponse inappropriée du serveur en amont ou d'origine. |
503 Service non disponible |
Signifie que le serveur n'est actuellement pas en mesure de traiter la demande en raison d'une surcharge temporaire ou d'une maintenance planifiée. Cela implique que le serveur est temporairement hors service, mais qu'il peut être à nouveau disponible après un certain temps. |
504 Délai d'attente de passerelle |
Indique qu'un client ou un proxy n'a pas reçu de réponse en temps voulu du serveur Web auquel il a tenté d'accéder pour charger la page Web ou répondre à une autre demande du navigateur. Cela implique souvent que le serveur en amont est en panne. |
Ici ....
Le trafic réseau transite entre l'adresse IP du client et l'adresse IP de l'interface proxy SWA (il s'agit généralement de l'interface P1, mais il peut s'agir de l'interface P2 ou de l'interface de gestion, selon la configuration du proxy).
Le trafic du client est destiné au port TCP 80 ou 3128 vers le SWA (les ports proxy SWA par défaut sont TCP 80 et 3128, dans cet exemple, nous utilisons le port 3128)
Le trafic réseau se produit entre l'adresse IP du proxy et l'adresse IP du serveur Web.
Le trafic provenant de SWA est destiné au port TCP 80 et provient d'un port aléatoire (et non du port proxy)
Voici un exemple de HTTP Get from Client
Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.
Remarque : chaque flux de trafic se distingue par une couleur différente ; le flux du client vers le SWA est d'une couleur et le flux du SWA vers le serveur Web en est une autre.
Voici un exemple de journaux d'accès :
1706172876.686 224 10.61.70.23 TCP_MISS/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",61.46,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 10, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 108, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 106, Response header = 0, Server response = 1, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 2, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 4; "25/Jan/2024:09:54:36 +0100" ][Client Port = 65238, Server IP = 10.184.216.34, Server Port = 80]
Cela représente le flux entier du trafic du client vers le SWA, lorsque les données se trouvent dans le cache SWA.
Remarque : comme vous pouvez le voir, le serveur Web renvoie la réponse HTTP 304 : Cache not Modified. (dans cet exemple, le paquet numéro 1947)
Voici un exemple de réponse HTTP 304
Voici un exemple de journaux d'accès :
1706173001.489 235 10.61.70.23 TCP_REFRESH_HIT/200 1721 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",58.59,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 150, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 110, Request Header = 0, Request to Server = 0, 1st byte to client = 2, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 119, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 1; "25/Jan/2024:09:56:41 +0100" ][Client Port = 55709, Server IP = 10.184.216.34, Server Port = 80]
Le trafic réseau transite entre l'adresse IP du client et l'adresse IP de l'interface proxy SWA (il s'agit généralement d'une interface P1, mais il peut s'agir d'une interface P2 ou d'une interface de gestion, selon la configuration du proxy).
Le trafic du client est destiné au port TCP 80 ou 3128 vers le SWA (les ports proxy SWA par défaut sont TCP 80 et 3128, dans cet exemple, nous utilisons le port 3128)
Voici les détails de Client Hello de Client à SWA, comme vous pouvez le voir dans l'indication de nom de serveur (SNI) l'URL du serveur Web peut être vu qui dans cet exemple, est www.example.com et le client annoncé 17 suites de chiffrement :
Conseil : vous pouvez utiliser ce filtre dans Wireshark pour rechercher URL/SNI : tls.handshake.extensions_server_name == "www.example.com"
Voici un exemple de certificat que SWA a envoyé au client
Le trafic réseau se produit entre l'adresse IP du proxy et l'adresse IP du serveur Web.
Le trafic provenant de SWA est destiné au port TCP 443 (et non au port proxy)
Voici les détails de Client Hello de SWA vers le serveur Web, comme vous pouvez le voir SWA annoncé 12 suites de chiffrement :
Remarque : les suites de chiffrement observées ici diffèrent des suites de chiffrement dans le paquet Hello du client à SWA, car le SWA, configuré pour déchiffrer ce trafic, utilise ses propres chiffrements.
Conseil : dans l'échange de clés de serveur de SWA vers le serveur Web, le certificat du serveur Web apparaît. Cependant, si un proxy en amont trouve la configuration pour votre SWA, son certificat s'affiche à la place du certificat du serveur Web.
Voici un exemple de HTTP CONNECT du client
Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.
Remarque : chaque flux de trafic se distingue par une couleur différente ; le flux du client vers le SWA est d'une couleur et le flux du SWA vers le serveur Web en est une autre.
Voici un exemple de journaux d'accès :
1706174571.215 582 10.61.70.23 TCP_MISS_SSL/200 39 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - DECRYPT_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.54,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1600, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 113, Request Header = 0, Request to Server = 0, 1st byte to client = 113, Response Header = 0, Client Body = 79 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 344, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 0; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]
1706174571.486 270 10.61.70.23 TCP_MISS_SSL/200 1106 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,1,"-",0,0,0,1,"-",-,-,-,"-",1,-,"-","-",-,-,"IW_ref",-,"Unknown","Reference","-","Unknown","Unknown","-","-",32.77,0,-,"Unknown","-",1,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 1630, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 3, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 264, Response header = 0, Server response = 2, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 1, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 1, AMP response = 0, AMP total = 0; Latency = 2; "25/Jan/2024:10:22:51 +0100" ][Client Port = 24953, Server IP = 10.184.216.34, Server Port = 443]
Remarque : comme vous pouvez le voir dans le déploiement transparent pour le trafic HTTPS, il y a 2 lignes dans les journaux d'accès, la première ligne est quand le trafic est chiffré et vous pouvez voir CONNECT et l'URL du serveur Web commence par tunnel://. Si le déchiffrement est activé dans SWA, la deuxième ligne contient GET et l'URL entière commence par HTTPS, ce qui signifie que le trafic a été déchiffré.
Si vous avez configuré votre SWA pour qu'il traverse le trafic, voici le flux global :
Voici l'exemple de Client Hello de SWA vers le serveur Web :
Identique à l'Hello client du client à SWA :
Voici un exemple de journal d'accès :
1706185288.920 53395 10.61.70.23 TCP_MISS/200 6549 CONNECT tunnel://www.example.com:443/ - DIRECT/www.example.com - PASSTHRU_WEBCAT_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"IW_ref",3.7,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"IW_ref",-,"-","Reference","-","Unknown","Unknown","-","-",0.98,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 210, User Agent = "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:122.0) Gecko/20100101 Firefox/122.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 233, Request Header = 0, Request to Server = 0, 1st byte to client = 119, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 0, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 436, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 22, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 0, AMP total = 0; Latency = 22; "25/Jan/2024:13:21:28 +0100" ][Client Port = 59939, Server IP = 10.184.216.34, Server Port = 443]
Remarque : comme vous pouvez le voir, il s'agit d'une seule ligne et l'action est PASSTHRU.
Le trafic réseau transite entre l’adresse IP du client et l’adresse IP du serveur Web.
Le trafic en provenance du client est destiné au port TCP 80 (et non au port proxy)
Voici un exemple de HTTP Get from Client
Le trafic réseau se produit entre l'adresse IP du proxy et l'adresse IP du serveur Web.
Le trafic provenant de SWA est destiné au port TCP 80 (et non au port proxy)
Voici un exemple de HTTP Get from Proxy
Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.
Remarque : chaque flux de trafic se distingue par une couleur différente ; le flux du client vers le SWA est d'une couleur et le flux du SWA vers le serveur Web en est une autre.
Voici un exemple de journaux d'accès :
1702318427.181 124 192.168.1.10 TCP_MISS/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",115.29,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 50, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 1, Request Header = 0, Client Body = 0, 1st response byte = 124, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 124>, AMP total = 124<; Latency = 1; "11/Dec/2023:19:13:47 +0100" ][Client Port = 54468, Server IP = 10.184.216.34, Server Port = 80]
Cela représente le flux entier du trafic du client vers le SWA, lorsque les données se trouvent dans le cache SWA.
Remarque : comme vous pouvez le voir, le serveur Web renvoie la réponse HTTP 304 : Cache not Modified. (dans cet exemple, paquet numéro 27)
Voici un exemple de réponse HTTP 304
Voici un exemple de journaux d'accès :
1702318789.560 105 192.168.1.10 TCP_REFRESH_HIT/200 1787 GET http://www.example.com/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",136.15,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 360, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 2, Request Header = 0, Client Body = 0, 1st response byte = 104, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 105>, AMP total = 105<; Latency = 2; "11/Dec/2023:19:19:49 +0100" ][Client Port = 54487, Server IP = 10.184.216.34, Server Port = 80]
Le trafic réseau transite entre l’adresse IP du client et l’adresse IP du serveur Web.
Le trafic du client est destiné au port TCP 443 (et non au port proxy)
Voici les détails de Client Hello de Client à SWA, comme vous pouvez le voir dans l'indication de nom de serveur (SNI) l'URL du serveur Web peut être vu qui dans cet exemple, est www.example.com .
Conseil : vous pouvez utiliser ce filtre dans Wireshark pour rechercher URL/SNI : tls.handshake.extensions_server_name == "www.example.com"
Voici un exemple d'échange de clés de serveur
Remarque : comme vous pouvez le voir, le certificat est celui qui a été configuré dans SWA comme certificat de déchiffrement.
Le trafic réseau se produit entre l'adresse IP du proxy et l'adresse IP du serveur Web.
Le trafic provenant de SWA est destiné au port TCP 443 (et non au port proxy)
Voici un exemple de client Hello de SWA vers Web Server
Remarque : les suites de chiffrement observées ici diffèrent des suites de chiffrement dans le paquet Hello du client à SWA, car le SWA, configuré pour déchiffrer ce trafic, utilise ses propres chiffrements.
Conseil : dans l'échange de clés de serveur de SWA vers le serveur Web, le certificat du serveur Web apparaît. Cependant, si un proxy en amont trouve la configuration pour votre SWA, son certificat s'affiche à la place du certificat du serveur Web.
Voici un exemple de journaux d'accès :
1702319784.943 558 192.168.1.10 TCP_MISS_SSL/200 0 TCP_CONNECT 10.184.216.34:443 - DIRECT/www.example.com - DECRYPT_ADMIN_DEFAULT_ACTION_7-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",0.00,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 940, User Agent = -, AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 0, Response Header = 0, Client Body = 50 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 45, Client Body = 0, 1st response byte = 0, Response header = 0, Server response = 249, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 5, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 558>, AMP total = 558<; Latency = 50; "11/Dec/2023:19:36:24 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]
1702319785.190 247 192.168.1.10 TCP_MISS_SSL/200 1676 GET https://www.example.com:443/ - DIRECT/www.example.com text/html DEFAULT_CASE_12-DefaultGroup-DefaultGroup-NONE-NONE-NONE-DefaultGroup-NONE <"-",-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,"-",-,"-","-","-","-","-","-","-",54.28,0,-,"-","-",-,"-",-,-,"-","-",-,-,"-",-,-> - - [ Request Details: ID = 960, User Agent = "curl/8.4.0", AD Group Memberships = ( NONE ) - ] [ Tx Wait Times (in ms): 1st byte to server = 0, Request Header = 0, Request to Server = 0, 1st byte to client = 50, Response Header = 50, Client Body = 0 ] [ Rx Wait Times (in ms): 1st request byte = 0, Request Header = 97, Client Body = 0, 1st response byte = 48, Response header = 0, Server response = 0, Disk Cache = 0; Auth response = 0, Auth total = 0; DNS response = 0, DNS total = 0, WBRS response = 0, WBRS total = 0, AVC response = 0, AVC total = 0, DCA response = 0, DCA total = 0, McAfee response = 0, McAfee total = 0, Sophos response = 0, Sophos total = 0, Webroot response = 0, Webroot total = 0, Anti-Spyware response = 0, Anti-Spyware total = 0, AMP response = 247>, AMP total = 247<; Latency = 97; "11/Dec/2023:19:36:25 +0100" ][Client Port = 54515, Server IP = 10.184.216.34, Server Port = 443]
Remarque : comme vous pouvez le voir dans le déploiement transparent pour le trafic HTTPS, il y a 2 lignes dans les journaux d'accès, la première ligne est quand le trafic est chiffré et vous pouvez voir TCP_CONNECT et l'adresse IP du serveur Web. Si le déchiffrement est activé dans SWA, la deuxième ligne contient GET et l'URL entière commence par HTTPS, ce qui signifie que le trafic a été déchiffré et SWA connaît l'URL.
Révision | Date de publication | Commentaires |
---|---|---|
1.0 |
13-May-2024 |
Première publication |