Verstehen des Paketflusses in einer sicheren Web-Appliance

Einleitung

In diesem Dokument wird der Netzwerkfluss in einem Proxy-konfigurierten Netzwerk beschrieben. Der Schwerpunkt liegt dabei auf der Secure Web Appliance (SWA).

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Grundlegende TCP/IP-Konzepte
• Grundkenntnisse der Proxy-Einrichtung.
• Grundkenntnisse des Authentifizierungsmechanismus, der in der Umgebung mit Proxy verwendet wird.

Verwendete Abkürzungen sind diese Artikel:

TCP: Transmission Control Protocol

UDP: User Datagram Protocol

IP: Internetprotokoll

GRE: Generic Routing Encapsulation

HTTP: Hypertext Transfer Protocol

HTTPS: Hypertext Transfer Protocol Secure

URL: Uniform Resource Locator

TLS: Transport Layer Security

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

Abgrenzungstypen der Proxybereitstellung 

TLS-Handshake

Ein TLS-Handshake in HTTPS tritt auf, wenn ein Client und ein Server über das Internet kommunizieren und so eine sichere Verbindung herstellen. Der Prozess schützt den Datenschutz und die Datenintegrität zwischen zwei kommunizierenden Anwendungen. Es arbeitet mit einer Reihe von Schritten, in denen Client und Server sich auf Verschlüsselungsstandards und -codes für alle nachfolgenden Übertragungen einigen. Der Handshake soll vor unbefugtem Zugriff oder Manipulation durch Dritte abschrecken. Es authentifiziert auch die Identität der kommunizierenden Parteien, um Identitätswechsel zu beseitigen. Dieser Prozess ist für HTTPS von entscheidender Bedeutung, da er die Sicherheit der Daten bei der Übertragung gewährleistet.

Dies sind die Schritte eines TLS-Handshakes:

1. Client Hello: Der Client initiiert den Handshake-Prozess mit einer Hello-Nachricht. Diese Nachricht enthält die Client-TLS-Version, unterstützte Verschlüsselungssuiten und eine zufällige Bytefolge, die als "client random" bezeichnet wird.

2. Server Hello: Der Server antwortet mit einer Hello-Nachricht. Diese Nachricht enthält die vom Server ausgewählte TLS-Version, die ausgewählte Verschlüsselungs-Suite, eine als "Server random" bekannte Zeichenfolge mit zufälligen Bytes und das digitale Serverzertifikat. Bei Bedarf fordert der Server auch das digitale Client-Zertifikat für die gegenseitige Authentifizierung an.

3. Client verifiziert das Serverzertifikat: Der Client überprüft das digitale Serverzertifikat bei der Zertifizierungsstelle, die es ausgestellt hat. Dadurch wird sichergestellt, dass der Client mit dem legitimen Server kommuniziert.

4. Pre-Master Secret: Der Client sendet eine zufällige Byte-Zeichenfolge, die als "Pre-Master Secret" bezeichnet wird und zur Erstellung der Sitzungsschlüssel beiträgt. Der Client verschlüsselt diesen Pre-Master-Schlüssel mit dem öffentlichen Schlüssel des Servers, sodass nur der Server ihn mit seinem privaten Schlüssel entschlüsseln kann.

5. Master Secret: Sowohl der Client als auch der Server verwenden den Pre-Master Secret und die zufälligen Byte-Strings aus den Hello-Nachrichten, um unabhängig voneinander den gleichen "Master Secret" zu berechnen. Dieser gemeinsame geheime Schlüssel ist die Grundlage für die Generierung der Sitzungsschlüssel.

6. Client Finished: Der Client sendet eine mit dem Sitzungsschlüssel verschlüsselte "Finished"-Nachricht, um den Abschluss des Client-Teils des Handshakes zu signalisieren.

7. Server Finished (Server beendet): Der Server sendet eine "Finished"-Nachricht, die ebenfalls mit dem Sitzungsschlüssel verschlüsselt ist, um den Abschluss des Server-Teils des Handshakes zu signalisieren.

HTTP-Antwortcode

1xx : Informativ

Code

Details

100 Fortfahren

Typisch für das ICAP-Protokoll. Dies ist eine Informationsantwort, die den Client darüber informiert, dass er weiterhin Daten senden kann. Bei ICAP-Diensten (wie z. B. Virenscans) kann der Server nur die erste x Bytemenge sehen wollen. Wenn das Scannen der ersten Bytes abgeschlossen ist und kein Virus entdeckt wurde, sendet es den Befehl 100 Continue, um den Client zu informieren und den Rest des Objekts zu senden.

2xx: Erfolgreich

Code	Details
200 OK	Der gängigste Antwortcode. Dies bedeutet, dass die Anforderung problemlos erfolgreich ist.

3xx: Umleitung

Code	Details
301 Permanente Weiterleitung	Dies ist eine permanente Umleitung. Sie können diesen Code sehen, wenn Sie zu www sub-domain umleiten.
302 Temporäre Umleitung	Dies ist eine vorübergehende Umleitung. Der Client wird angewiesen, eine neue Anforderung für das im Location:-Header angegebene Objekt zu erstellen.
304 Nicht geändert	Dies ist als Antwort auf ein GIMS (GET If-modified-since). Hierbei handelt es sich buchstäblich um eine Standard-HTTP-GET, die den Header If-modified-since: <date> enthält. Dieser Header teilt dem Server mit, dass sich im lokalen Cache des Clients eine Kopie des angeforderten Objekts befindet, die das Datum enthält, an dem das Objekt abgerufen wurde. Wenn das Objekt seit diesem Datum geändert wurde, antwortet der Server mit 200 OK und einer neuen Kopie des Objekts. Wenn sich das Objekt seit dem Abrufdatum nicht geändert hat, sendet der Server eine 304 Not Modified-Antwort zurück.
307-Authentifizierungsumleitung	Dies zeigt sich vor allem bei der transparenten Proxy-Bereitstellung, wenn der Proxy-Server so konfiguriert ist, dass er die Anforderung authentifiziert und die Anforderung an eine andere URL umleitet, um den Benutzer zu authentifizieren.

4xx-Codes: Client-Fehler

Code	Details
400 Ungültige Anforderung	Dies deutet auf ein Problem mit der HTTP-Anfrage hin, da sie nicht der richtigen Syntax entspricht. Mögliche Gründe können mehrere Header in einer einzelnen Zeile, Leerzeichen innerhalb eines Headers oder das Fehlen von HTTP/1.1 im URI sein. Die richtige Syntax finden Sie in RFC 2616.
401 Nicht autorisiert Webserverauthentifizierung erforderlich	Der Zugriff auf das angeforderte Objekt erfordert eine Authentifizierung. Der 401-Code wird zur Authentifizierung mit einem Ziel-Webserver verwendet. Wenn der SWA im transparenten Modus arbeitet und die Authentifizierung auf dem Proxy aktiviert ist, gibt er eine 401 an den Client zurück, da sich die Appliance so darstellt, als wäre sie der OCS (Original Content Server). Die Authentifizierungsmethoden, die verwendet werden können, werden in einem HTTP-Antwort-Header "www-Authenticate:" beschrieben. Dadurch wird der Client informiert, ob der Server NTLM, eine einfache oder eine andere Form der Authentifizierung anfordert.
403 abgelehnt	Der Client kann nicht auf das angeforderte Objekt zugreifen. Verschiedene Gründe können dazu führen, dass ein Server den Objektzugriff verweigert. Der Server liefert in der Regel eine Ursachenbeschreibung innerhalb der HTTP-Daten- oder HTML-Antwort.
404 Nicht gefunden	Das angeforderte Objekt ist auf dem Server nicht vorhanden.
407 Proxy-Authentifizierung erforderlich	Dies ist dasselbe wie ein 401, mit der Ausnahme, dass es speziell für die Authentifizierung an einem Proxy und nicht dem OCS dient. Diese wird nur gesendet, wenn die Anforderung explizit an den Proxy gesendet wurde. Ein 407 kann nicht an einen Client gesendet werden, während SWA als transparenter Proxy konfiguriert ist, da der Client nicht weiß, dass der Proxy vorhanden ist. Wenn dies der Fall ist, wird der Client höchstwahrscheinlich den TCP-Socket FIN oder RST starten.

5xx: Serverfehler

Code	Details
501 Interner Serverfehler	Generischer Webserverfehler.
502 Ungültiges Gateway	Tritt auf, wenn ein Server, der als Gateway oder Proxy fungiert, eine ungültige Antwort von einem eingehenden Server empfängt. Es signalisiert, dass das Gateway eine unangemessene Antwort vom Upstream- oder Ursprungsserver erhalten hat.
503 Dienst nicht verfügbar	Zeigt an, dass der Server derzeit aufgrund einer vorübergehenden Überlastung oder geplanter Wartung nicht in der Lage ist, die Anforderung zu bearbeiten. Dies bedeutet, dass der Server vorübergehend außer Betrieb ist, aber nach einiger Zeit wieder verfügbar sein kann.
504 Gateway-Zeitüberschreitung	Zeigt an, dass ein Client oder Proxy keine zeitnahe Antwort vom Webserver erhalten hat, auf den er zugreifen wollte, um die Webseite zu laden oder eine andere Anforderung des Browsers zu erfüllen. Dies bedeutet oft, dass der Upstream-Server ausgefallen ist.

Explizite Bereitstellung

Hier ....

HTTP-Datenverkehr bei expliziter Bereitstellung ohne Authentifizierung 

Client und SWA

Der Netzwerkverkehr verläuft zwischen der IP-Adresse des Clients und der IP-Adresse der SWA-Proxyschnittstelle (in der Regel handelt es sich um die P1-Schnittstelle, kann aber auch die P2- oder die Management-Schnittstelle sein, hängt von der Proxy-Konfiguration ab).

Der Datenverkehr vom Client ist für TCP-Port 80 oder 3128 zum SWA bestimmt (Standard-SWA-Proxyports sind TCP 80 und 3128, in diesem Beispiel verwenden wir Port 3128).  

• TCP-Handshake 
• HTTP Get from Client (Ziel-IP = SWA-IP, Ziel-Port = 3128) 
• HTTP-Antwort vom Proxy (Quell-IP = SWA)
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image-Client an SWA, expliziter HTTP-Modus

SWA und Webserver

Der Netzwerkverkehr erfolgt zwischen der IP-Adresse des Proxys und der IP-Adresse des Webservers.

Der Datenverkehr von SWA wird an TCP-Port 80 weitergeleitet und von einem zufälligen Port (nicht dem Proxy-Port) empfangen. 

• TCP-Handshake 
• HTTP Get from Proxy (Ziel-IP = Webserver, Ziel-Port = 80) 
• HTTP-Antwort vom Webserver ( Quell-IP = Proxyserver) 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image - HTTP-SWA zu Webserver-Explicit-kein Cache

Hier ist ein Beispiel für HTTP Get from Client 

Image - Client an SWA HTTP GET - explizit

Dieser Wert stellt den gesamten Datenverkehrsfluss vom Client zum SWA, dann zum Webserver und schließlich zurück zum Client dar.

Image - Gesamter HTTP Explicit-no Cache

Image - Datenverkehrsfluss HTTP Explicit - kein Cache

Beispiel für AccessLogs: 

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]

Datenverkehr mit zwischengespeicherten Daten

Dieser Wert stellt den gesamten Datenverkehrsfluss vom Client zum SWA dar, wenn sich die Daten im SWA-Cache befinden.  

Bild - Explizit zwischengespeicherte HTTP-Daten

Image - Flow HTTP explizit mit Cache

Nachfolgend finden Sie ein Beispiel für die HTTP-Antwort 304.

Bild - explizite HTTP-304-Antwort

Beispiel für AccessLogs: 

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]

HTTP-Datenverkehr bei expliziter Bereitstellung ohne Authentifizierung 

Client und SWA

Der Netzwerkverkehr verläuft zwischen der IP-Adresse des Clients und der IP-Adresse der SWA-Proxyschnittstelle (in der Regel handelt es sich um die P1-Schnittstelle, kann aber auch die P2- oder die Management-Schnittstelle sein, je nach Proxy-Konfiguration).

Der Datenverkehr vom Client ist für TCP-Port 80 oder 3128 zum SWA bestimmt (Standard-SWA-Proxyports sind TCP 80 und 3128, in diesem Beispiel verwenden wir Port 3128).  

• TCP-Handshake 
• HTTP CONNECT vom Client (Ziel-IP = SWA, Ziel-Port = 3128) 
• HTTP-Antwort vom Proxy (Quell-IP = SWA)
• Client Hello mit SNI der URL (Quell-IP = Client)
• Server Hello ( Quell-IP = SWA )
• Server Key Exchange (Quell-IP = SWA) 
• Client Key Exchange (Quell-IP = Client) 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image - HTTPS-Client an SWA-Explicit - kein Cache

Hier sind Details von Client Hello von Client an SWA, wie Sie in der Server Name Indication (SNI) die URL des Webservers sehen können, die in diesem Beispiel www.example.com ist und von dem Client 17 Cipher Suites angekündigt wurde:

Bild - HTTPS-Client hello - Explizit - Client an SWA

Hier ist ein Beispiel für ein Zertifikat, das SWA an den Client gesendet hat: 

Image - HTTPS-Zertifikat - Explizit - SWA an Client

SWA und Webserver

Der Netzwerkverkehr erfolgt zwischen der IP-Adresse des Proxys und der IP-Adresse des Webservers.

Der Datenverkehr von SWA ist für TCP-Port 443 bestimmt (nicht für den Proxy-Port) 

• TCP-Handshake 
• Client Hello (Ziel-IP = Webserver, Ziel-Port = 443 ) 
• Server Hello ( Quell-IP = Webserver ) 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Bild - HTTPS - explizit - SWA an Webserver

Hier sind die Details von Client Hello von SWA zum Webserver, wie Sie sehen können, dass SWA 12 Cipher Suites angekündigt hat:

Bild - HTTPS-Client Hello - SWA zum Webserver- Kein Chache

Hier ist ein Beispiel für HTTP CONNECT vom Client 

Bild - Client HTTP Connect

Dieser Wert stellt den gesamten Datenverkehrsfluss vom Client zum SWA, dann zum Webserver und schließlich zurück zum Client dar.

Bild - Vollständiges explizites HTTPS ohne Cache

Image - HTTPS-Fluss - explizit - kein Cache

Beispiel für AccessLogs: 

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]

HTTPS-Passthrough-Datenverkehr

Wenn Sie die SWA so konfiguriert haben, dass der Datenverkehr weitergeleitet wird, lautet der Gesamtfluss wie folgt: 

Image - HTTPS-Passthrough - Explizit - Fluss

Beispiel für Client Hello von SWA auf Webserver:

Bild - HTTPS-Passthrough - Explizit - SWA an Webserver - Client hello

Dies entspricht dem "Client Hello"-Vorgang vom Client zur SWA:

Bild - HTTPS-Passthrough - Explizit - Client an SWA - Client hello

Hier ein Beispiel für ein Accesslog:

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]

Transparente Bereitstellung 

HTTP-Datenverkehr bei transparenter Bereitstellung ohne Authentifizierung

Client und SWA

Netzwerkverkehr wird zwischen der IP-Adresse des Clients und der IP-Adresse des Webservers übertragen.

Der Datenverkehr vom Client ist für TCP-Port 80 bestimmt (nicht für den Proxy-Port)  

• TCP-Handshake 
• HTTP Get from Client (Ziel-IP = Webserver, Ziel-Port = 80) 
• HTTP-Antwort vom Proxy ( Quell-IP = Webserver)
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image - Client zu Proxy - HTTP - Transparent - Keine Authentifizierung

Hier ist ein Beispiel für HTTP Get from Client. 

Image - Client zu Proxy - HTTP - Transparent - Keine Auth - Client HTTP Get

SWA und Webserver

Der Netzwerkverkehr erfolgt zwischen der IP-Adresse des Proxys und der IP-Adresse des Webservers.

Der Datenverkehr von SWA ist für TCP-Port 80 bestimmt (nicht für den Proxy-Port) 

• TCP-Handshake 
• HTTP Get from Proxy (Ziel-IP = Webserver, Ziel-Port = 80) 
• HTTP-Antwort vom Webserver ( Quell-IP = Proxyserver) 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image- Proxy und Webserver - HTTP - Transparent - Keine Authentifizierung

Nachfolgend finden Sie ein Beispiel für den HTTP-Abruf vom Proxy. 

Image- Proxy an Webserver - HTTP - Transparent - Keine Auth - Proxy HTTP Get

Dieser Wert stellt den gesamten Datenverkehrsfluss vom Client zum SWA, dann zum Webserver und schließlich zurück zum Client dar.

Bild - Gesamtverkehr - HTTP - Transparent - Keine Authentifizierung  

Bild - WCCP-HTTP-Fluss

Beispiel für AccessLogs: 

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]

Datenverkehr mit zwischengespeicherten Daten

Dieser Wert stellt den gesamten Datenverkehrsfluss vom Client zum SWA dar, wenn sich die Daten im SWA-Cache befinden.  

Bild - Zwischengespeichert - Gesamtverkehr - HTTP - Transparent - Keine Authentifizierung

Nachfolgend finden Sie ein Beispiel für die HTTP-Antwort 304.

Bild - Zwischengespeichert - HTTP-Antwort 304 - HTTP - Transparent - Keine Authentifizierung

Beispiel für AccessLogs: 

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]

HTTP-Datenverkehr bei transparenter Bereitstellung ohne Authentifizierung

Client und SWA

Netzwerkverkehr wird zwischen der IP-Adresse des Clients und der IP-Adresse des Webservers übertragen.

Der Datenverkehr vom Client ist für TCP-Port 443 bestimmt (nicht für den Proxy-Port)  

• TCP-Handshake 
• TLS Handshake Client Hello - Server Hello - Serverschlüsselaustausch - Clientschlüsselaustausch 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image - Client zu Proxy - HTTPs - Transparent - Keine Authentifizierung

Hier sind Details von Client Hello von Client an SWA, wie Sie in der Server Name Indication (SNI) die URL des Webservers sehen können, die in diesem Beispiel www.example.com ist.

Image - Client Hello - Client an Proxy - Transparent - Keine Authentifizierung

Hier ist ein Beispiel für Server Key Exchange.

Image- Serverschlüsselaustausch - Client zu Proxy - Transparent - Keine Authentifizierung

SWA und Webserver

Der Netzwerkverkehr erfolgt zwischen der IP-Adresse des Proxys und der IP-Adresse des Webservers.

Der Datenverkehr von SWA ist für TCP-Port 443 bestimmt (nicht für den Proxy-Port) 

• TCP-Handshake 
• TLS Handshake Client Hello - Server Hello - Serverschlüsselaustausch - Clientschlüsselaustausch 
• Datenübertragung
• TCP-Verbindungsabschluss (4-Wege-Handshake)

Image- Proxy an Webserver - HTTPs - Transparent - Keine Authentifizierung

Hier ist ein Beispiel für Client Hello von SWA zu Webserver

Image - Client Hello - Proxy zu Webserver - Transparent - Keine Authentifizierung

Beispiel für AccessLogs:

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]

Zugehörige Informationen

• Technischer Support und Dokumentation für Cisco Systeme
• Konfigurieren von Leistungsparametern in Zugriffsprotokollen - Cisco