Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Différents types de déploiement de proxy

Connexion TLS

Code de réponse HTTP

1xx : informatif

2xx : Réussite

3xx : redirection

Codes 4xx : erreur client

5xx : erreur de serveur

Déploiement explicite

Trafic HTTP dans un déploiement explicite sans authentification

Client et SWA

Serveur Web et SWA

Trafic Avec Données Mises En Cache

Trafic HTTP dans un déploiement explicite sans authentification

Client et SWA

Serveur Web et SWA

Trafic HTTPS de transit

Déploiement transparent

Trafic HTTP dans un déploiement transparent sans authentification

Client et SWA

Serveur Web et SWA

Trafic Avec Données Mises En Cache

Trafic HTTP dans un déploiement transparent sans authentification

Client et SWA

Serveur Web et SWA

Informations connexes

Introduction

Ce document décrit le flux réseau dans le réseau configuré par proxy, en particulier sur l'appareil Web sécurisé (SWA).

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

- Concepts TCP/IP de base.

- Connaissances de base de la configuration du proxy.

- Connaissance de base du mécanisme d'authentification utilisé dans un environnement avec proxy.

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

Composants utilisés

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.

Différents types de déploiement de proxy

Connexion TLS

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 :

1. 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 ».

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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 de réponse HTTP

1xx : informatif

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.

2xx : Réussite

Code

Détails

200 OK

Code de réponse le plus courant. Cela signifie que la demande a abouti sans aucun problème.

3xx : redirection

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,

Codes 4xx : erreur client

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.

5xx : erreur de serveur

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.

Déploiement explicite

Ici ....

Trafic HTTP dans un déploiement explicite sans authentification

Client et SWA

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)

- Connexion TCP.

- HTTP Get from Client (IP de destination = IP SWA , Port de destination = 3128 )

- Réponse HTTP du proxy ( IP source = SWA )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image-Client vers SWA, mode HTTP Explicit

Serveur Web et SWA

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)

- Connexion TCP.

- HTTP Get from Proxy (Adresse IP de destination = serveur Web , Port de destination = 80 )

- Réponse HTTP du serveur Web ( IP source = serveur proxy )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image- HTTP-SWA vers serveur Web-Explicit-no cache

Voici un exemple de HTTP Get from Client

Image- Client vers SWA HTTP GET- Explicit

Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.

Image - Tout le trafic HTTP Explicit-no cache

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.

Image - Flux de trafic HTTP explicite - pas de cache

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]

Trafic Avec Données Mises En Cache

Cela représente le flux entier du trafic du client vers le SWA, lorsque les données se trouvent dans le cache SWA.

Image - Données HTTP explicites mises en cache

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)

Image - Flux HTTP explicite avec cache

Voici un exemple de réponse HTTP 304

Image- Réponse HTTP Explicit 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]

Trafic HTTP dans un déploiement explicite sans authentification

Client et SWA

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)

- Connexion TCP.

- HTTP CONNECT à partir du client (IP de destination = SWA , port de destination = 3128 )

- Réponse HTTP du proxy ( IP source = SWA )

- Client Hello avec SNI de l'URL (IP source = Client)

- Hello du serveur ( IP source = SWA )

- Échange de clés de serveur ( IP source = SWA)

- Échange de clés client ( IP source = Client )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image- Client HTTPS vers SWA-Explicit- Pas de cache

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 :

Image - Hello du client HTTPS - Explicite - Client vers SWA

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

Image - Certificat HTTPS - Explicite - SWA au client

Serveur Web et SWA

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)

- Connexion TCP.

- Client Hello (Adresse IP de destination = serveur Web , Port de destination = 443 )

- Hello du serveur ( IP source = serveur Web )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image- HTTPS - Explicit - SWA vers serveur Web

Voici les détails de Client Hello de SWA vers le serveur Web, comme vous pouvez le voir SWA annoncé 12 suites de chiffrement :

Image- Client HTTPS Hello - SWA vers serveur Web- Pas de cache

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

Image - Client HTTP Connect

Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.

Image - HTTPS explicite complet - Pas de cache

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.

Image- Flux HTTPS- Explicite - Pas de cache

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é.

Trafic HTTPS de transit

Si vous avez configuré votre SWA pour qu'il traverse le trafic, voici le flux global :

Image - Passthrough HTTPS - Explicite - Flux

Voici l'exemple de Client Hello de SWA vers le serveur Web :

Image - Passthrough HTTPS - Explicite - SWA vers Webserver - Hello du client

Identique à l'Hello client du client à SWA :

Image - Passthrough HTTPS - Explicite - Client vers SWA - Hello du client

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.

Déploiement transparent

Trafic HTTP dans un déploiement transparent sans authentification

Client et SWA

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)

- Connexion TCP.

- HTTP Get from Client (Adresse IP de destination = serveur Web , Port de destination = 80 )

- Réponse HTTP du proxy ( IP source = serveur Web )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image - Client vers proxy - HTTP - Transparent - Aucune authentification

Voici un exemple de HTTP Get from Client

Image - Client vers proxy - HTTP - Transparent - Aucune authentification - Client HTTP Get

Serveur Web et SWA

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)

- Connexion TCP.

- HTTP Get from Proxy (Adresse IP de destination = serveur Web , Port de destination = 80 )

- Réponse HTTP du serveur Web ( IP source = serveur proxy )

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image - Proxy et serveur Web - HTTP - Transparent - Aucune authentification

Voici un exemple de HTTP Get from Proxy

Image - Proxy vers serveur Web - HTTP - Transparent - Pas d'authentification - Proxy HTTP Get

Cela représente l'ensemble du flux de trafic du client vers le SWA, puis vers le serveur Web, et enfin vers le client.

Image - Trafic total - HTTP - Transparent - Aucune authentification

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.

Image- Flux HTTP WCCP

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]

Trafic Avec Données Mises En Cache

Cela représente le flux entier du trafic du client vers le SWA, lorsque les données se trouvent dans le cache SWA.

Image - Mise en cache - Trafic total - HTTP - Transparent - Aucune authentification

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

Image - Mise en cache - Réponse HTTP 304 - HTTP - Transparent - Aucune authentification

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]

Trafic HTTP dans un déploiement transparent sans authentification

Client et SWA

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)

- Connexion TCP.

- TLS Handshake Client Hello - Server Hello - Server Key Exchange - Client Key Exchange

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image - Client vers proxy - HTTPs - Transparent - Aucune authentification

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 .

Image - Client Hello - Client vers proxy - Transparent - Aucune authentification

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

Image - Échange de clés serveur - Client vers proxy - Transparent - Pas d'authentification

Remarque : comme vous pouvez le voir, le certificat est celui qui a été configuré dans SWA comme certificat de déchiffrement.

Serveur Web et SWA

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)

- Connexion TCP.

- TLS Handshake Client Hello - Server Hello - Server Key Exchange - Client Key Exchange

- Transfert de données

- Fin de connexion TCP (connexion en 4 étapes)

Image - Proxy vers serveur Web - HTTPs - Transparent - Aucune authentification

Voici un exemple de client Hello de SWA vers Web Server

Image- Client Hello - Proxy vers serveur Web - Transparent - Aucune authentification

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.

Informations connexes

- Assistance et documentation techniques - Cisco Systems

- Configuration du paramètre de performance dans les journaux d'accès - Cisco