Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Abgrenzungstypen der Proxybereitstellung

TLS-Handshake

HTTP-Antwortcode

1xx : Informativ

2xx: Erfolgreich

3xx:Umleitung

4xx-Codes: Client-Fehler

5xx: Serverfehler

Explizite Bereitstellung

HTTP-Datenverkehr bei expliziter Bereitstellung ohne Authentifizierung

Client und SWA

SWA und Webserver

Datenverkehr mit zwischengespeicherten Daten

HTTP-Datenverkehr bei expliziter Bereitstellung ohne Authentifizierung

Client und SWA

SWA und Webserver

HTTPS-Passthrough-Datenverkehr

Transparente Bereitstellung

HTTP-Datenverkehr bei transparenter Bereitstellung ohne Authentifizierung

Client und SWA

SWA und Webserver

Datenverkehr mit zwischengespeicherten Daten

HTTP-Datenverkehr bei transparenter Bereitstellung ohne Authentifizierung

Client und SWA

SWA und Webserver

Zugehörige Informationen

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

Hinweis: Jeder Datenverkehrsstrom zeichnet sich durch eine andere Farbe aus. Der Datenverkehrsfluss vom Client zum SWA ist eine Farbe, der Datenverkehrsfluss vom SWA zum Webserver eine andere.

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

Hinweis: Wie Sie sehen, gibt der Webserver die HTTP-Antwort 304: Cache not Modified (Cache nicht geändert) zurück. (in diesem Beispiel Paketnummer 1947)

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

Tipp: Sie können diesen Filter in Wireshark verwenden, um nach URL/SNI zu suchen: tls.handshake.extensions_server_name == "www.example.com"

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

Hinweis: Die hier beobachteten Cipher Suites unterscheiden sich von den Cipher Suites in Client Hello von Client zu SWA, da die SWA, die für die Entschlüsselung dieses Datenverkehrs konfiguriert ist, ihre eigenen Ciphers verwendet.

Tipp: Im Fenster Server Key Exchange (Serverschlüsselaustausch von SWA zu Webserver) wird das Webserverzertifikat angezeigt. Wenn ein Upstreamproxy jedoch eine Konfiguration für Ihren SWA findet, wird sein Zertifikat anstelle des Webserverzertifikats angezeigt.

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

Hinweis: Jeder Datenverkehrsstrom zeichnet sich durch eine andere Farbe aus. Der Datenverkehrsfluss vom Client zum SWA ist eine Farbe, der Datenverkehrsfluss vom SWA zum Webserver eine andere.

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]

Hinweis: Wie Sie bei einer transparenten Bereitstellung für HTTPS-Datenverkehr sehen können, gibt es in AccessLogs zwei Zeilen. Die erste Zeile lautet, wenn der Datenverkehr verschlüsselt ist, und Sie können CONNECT sehen, und die URL des Webservers beginnt mit tunnel://. Wenn die Entschlüsselung in SWA aktiviert ist, enthält die zweite Zeile GET, und die gesamte URL beginnt mit HTTPS, d. h. der Datenverkehr wurde entschlüsselt.

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]

Hinweis: Wie Sie sehen können, ist es nur eine Zeile und die Aktion ist PASSTHRU.

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

Hinweis: Jeder Datenverkehrsstrom zeichnet sich durch eine andere Farbe aus. Der Datenverkehrsfluss vom Client zum SWA ist eine Farbe, der Datenverkehrsfluss vom SWA zum Webserver eine andere.

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

Hinweis: Wie Sie sehen, gibt der Webserver die HTTP-Antwort 304: Cache not Modified (Cache nicht geändert) zurück. (in diesem Beispiel: Paketnummer 27)

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

Tipp: Sie können diesen Filter in Wireshark verwenden, um nach URL/SNI zu suchen: tls.handshake.extensions_server_name == "www.example.com"

Hier ist ein Beispiel für Server Key Exchange.

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

Hinweis: Wie Sie sehen, wurde das Zertifikat in SWA als Entschlüsselungszertifikat konfiguriert.

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

Hinweis: Die hier beobachteten Cipher Suites unterscheiden sich von den Cipher Suites in Client Hello von Client zu SWA, da die SWA, die für die Entschlüsselung dieses Datenverkehrs konfiguriert ist, ihre eigenen Ciphers verwendet.

Tipp: Im Fenster Server Key Exchange (Serverschlüsselaustausch von SWA zu Webserver) wird das Webserverzertifikat angezeigt. Wenn ein Upstreamproxy jedoch eine Konfiguration für Ihren SWA findet, wird sein Zertifikat anstelle des Webserverzertifikats angezeigt.

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]

Hinweis: Wie Sie bei einer transparenten Bereitstellung für HTTPS-Datenverkehr sehen können, gibt es in AccessLogs zwei Zeilen. Die erste Zeile lautet, wenn der Datenverkehr verschlüsselt ist, und Sie können TCP_CONNECT und die IP-Adresse des Webservers sehen. Wenn die Entschlüsselung in SWA aktiviert ist, enthält die zweite Zeile GET, und die gesamte URL beginnt mit HTTPS. Das bedeutet, der Datenverkehr wurde entschlüsselt, und SWA kennt die URL.

Zugehörige Informationen

- Technischer Support und Dokumentation für Cisco Systeme

- Konfigurieren von Leistungsparametern in Zugriffsprotokollen - Cisco