Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Tipi di distribuzione proxy differiti

Handshake TLS

Codice di risposta HTTP

1xx : Informativo

2xx: riuscito

3xx:Reindirizzamento

Codici 4xx: Errore del client

5xx: Errore del server

Distribuzione esplicita

Traffico HTTP nella distribuzione esplicita senza autenticazione

Client e SWA

SWA e server Web

Traffico Con Dati Memorizzati Nella Cache

Traffico HTTP in distribuzione esplicita senza autenticazione

Client e SWA

SWA e server Web

Traffico HTTPS pass-through

Distribuzione trasparente

Traffico HTTP nella distribuzione trasparente senza autenticazione

Client e SWA

SWA e server Web

Traffico Con Dati Memorizzati Nella Cache

Traffico HTTP nella distribuzione trasparente senza autenticazione

Client e SWA

SWA e server Web

Informazioni correlate

Introduzione

Questo documento descrive il flusso di rete nella rete configurata dal proxy, in particolare per le appliance Web protette (SWA).

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

- Concetti base di TCP/IP.

- Conoscenze base di configurazione proxy.

- Conoscenze base del meccanismo di autenticazione utilizzato nell'ambiente con Proxy.

Le abbreviazioni utilizzate in questi articoli sono:

TCP: Transmission Control Protocol

UDP: User Datagram Protocol

IP: Internet Protocol

GRE: Generic Routing Encapsulation

HTTP: protocollo di trasferimento ipertestuale.

HTTPS: protocollo di trasferimento ipertestuale protetto.

URL: Uniform Resource Locator

TLS: Transport Layer Security

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Tipi di distribuzione proxy differiti

Handshake TLS

Un handshake TLS in HTTPS si verifica quando un client e un server comunicano su Internet, fornendo una connessione protetta. Il processo mantiene la privacy e l'integrità dei dati tra due applicazioni in comunicazione. Opera attraverso una serie di fasi in cui client e server concordano sugli standard e i codici di crittografia per tutte le trasmissioni successive. L'handshake mira a scoraggiare qualsiasi accesso o manipolazione non autorizzata da parte di terzi. Inoltre, autentica l'identità delle parti comunicanti per eliminare la rappresentazione. Questo processo è cruciale in HTTPS in quanto garantisce che i dati rimangano sicuri mentre sono in transito.

Di seguito sono riportati i passaggi di un handshake TLS:

1. Salve client: il client avvia il processo di handshake con un messaggio di saluto. Questo messaggio contiene la versione TLS del client, le suite di cifratura supportate e una stringa di byte casuale nota come "client random".

2. Server Hello: il server risponde con un messaggio di benvenuto. Questo messaggio include la versione TLS scelta dal server, la suite di cifratura selezionata, una stringa di byte casuale nota come "server random" e il certificato digitale del server. Se necessario, il server richiede anche il certificato digitale del client per l'autenticazione reciproca.

3. Il client verifica il certificato del server: il client controlla il certificato digitale del server presso l'autorità di certificazione che lo ha emesso. In questo modo il client è sicuro di comunicare con il server legittimo.

4. Segreto pre-master: il client invia una stringa di byte casuale, nota come "segreto pre-master", che contribuisce alla creazione delle chiavi di sessione. Il client crittografa questo segreto pre-master con la chiave pubblica del server, in modo che solo il server possa decrittografarlo con la propria chiave privata.

5. Master Secret: sia il client che il server utilizzano il segreto pre-master e le stringhe di byte casuali dei messaggi hello per calcolare in modo indipendente lo stesso "master secret". Questo segreto condiviso costituisce la base per la generazione delle chiavi di sessione.

6. Client completato: il client invia un messaggio "Fine", crittografato con la chiave di sessione, per segnalare il completamento della parte client dell'handshake.

7. Server completato: il server invia un messaggio "Finito", anch'esso crittografato con la chiave di sessione, per segnalare il completamento della parte server dell'handshake.

Codice di risposta HTTP

1xx : Informativo

Codice

Dettagli

100 Continua

Generalmente visto in relazione al protocollo ICAP. Si tratta di una risposta informativa che informa il client della possibilità di continuare a inviare dati. Per quanto riguarda i servizi ICAP (ad esempio la scansione dei virus), il server può visualizzare solo la prima x quantità di byte. Al termine della scansione del primo set di byte e quando non è stato rilevato alcun virus, viene inviato il messaggio 100 Continue per comunicare al client di inviare il resto dell'oggetto.

2xx: operazione riuscita

Codice

Dettagli

200

Codice di risposta più comune. Ciò significa che la richiesta è stata completata senza alcun problema.

3xx: Reindirizzamento

Codice

Dettagli

301 Reindirizzamento permanente

Si tratta di un reindirizzamento permanente. Questo codice è visibile quando si esegue il reindirizzamento al sottodominio www.

302 - Reindirizzamento temporaneo

Si tratta di un reindirizzamento temporaneo. Al client viene richiesto di effettuare una nuova richiesta per l'oggetto specificato nell'intestazione Location:.

304 Non modificato

Questo è in risposta a un GIMS (GET If-Modified-Since). Si tratta letteralmente di un HTTP GET standard che include l'intestazione If-modified-Since: <data>. Questa intestazione indica al server che il client dispone di una copia dell'oggetto richiesto nella cache locale e indica la data in cui l'oggetto è stato recuperato. Se l'oggetto è stato modificato dopo tale data, il server risponde con 200 OK e una nuova copia dell'oggetto. Se l'oggetto non è stato modificato dopo la data di recupero, il server restituisce una risposta 304 Non modificato.

Reindirizzamento autenticazione 307

Questa situazione si verifica principalmente nella distribuzione proxy trasparente, quando il server proxy è configurato per autenticare la richiesta e reindirizza la richiesta a un altro URL per autenticare l'utente,

Codici 4xx: Errore del client

Codice

Dettagli

400 Richiesta non valida

Ciò indica un problema con la richiesta HTTP, in quanto non è conforme alla sintassi corretta. Le possibili cause possono includere più intestazioni su una singola riga, spazi all'interno di un'intestazione o la mancanza di HTTP/1.1 nell'URI, tra le altre. Per la sintassi corretta, consultare la RFC 2616.

401 Non autorizzato

Autenticazione server Web richiesta

L'accesso all'oggetto richiesto richiede l'autenticazione. Il codice 401 viene utilizzato per l'autenticazione con un server Web di destinazione. Quando il dispositivo SWA opera in modalità trasparente e l'autenticazione è abilitata sul proxy, restituisce un valore 401 al client, poiché l'accessorio si presenta come se fosse il server OCS (source content server).

I metodi di autenticazione che è possibile utilizzare sono descritti in dettaglio in un'intestazione di risposta HTTP 'www-authenticate:'. In questo modo il client viene informato se il server richiede l'autenticazione NTLM, di base o altre forme di autenticazione.

403 negato

Il client non può accedere all'oggetto richiesto. Vari motivi possono indurre un server a negare l'accesso agli oggetti. Il server in genere fornisce una descrizione della causa all'interno dei dati HTTP o della risposta HTML.

404 non trovato

L'oggetto richiesto non esiste nel server.

Autenticazione proxy 407 richiesta

È lo stesso di un 401, con la differenza che è specificamente per l'autenticazione a un proxy e non a OCS. Questo viene inviato solo se la richiesta è stata inviata esplicitamente al proxy.

Non è possibile inviare uno switch 407 a un client mentre SWA è configurato come proxy trasparente, in quanto il client non sa che il proxy esiste. In questo caso, è molto probabile che il client includa FIN o RST nel socket TCP.

5xx: errore del server

Codice

Dettagli

Errore interno del server 501

Errore generico del server Web.

502 Gateway non valido

Si verifica quando un server che funge da gateway o proxy riceve una risposta non valida da un server in ingresso. Segnala che il gateway ha ricevuto una risposta non appropriata dal server di origine o a monte.

503 Servizio non disponibile

Indica che il server non è attualmente in grado di gestire la richiesta a causa di un sovraccarico temporaneo o di una manutenzione pianificata. Ciò implica che il server è temporaneamente fuori servizio ma può essere nuovamente disponibile in seguito.

Timeout gateway 504

Indica che un client o un proxy non ha ricevuto una risposta tempestiva dal server Web a cui ha tentato di accedere per caricare la pagina Web o per soddisfare un'altra richiesta del browser. Ciò implica spesso che il server upstream non è attivo.

Distribuzione esplicita

Ecco...

Traffico HTTP nella distribuzione esplicita senza autenticazione

Client e SWA

Il traffico di rete passa tra l'indirizzo IP del client e l'indirizzo IP dell'interfaccia proxy SWA (di solito si tratta dell'interfaccia P1, ma può essere P2 o l'interfaccia di gestione, a seconda della configurazione del proxy).

Il traffico proveniente dal client è destinato alla porta TCP 80 o 3128 per l'interfaccia SWA (le porte proxy SWA predefinite sono TCP 80 e 3128, in questo esempio viene utilizzata la porta 3128)

- Handshake TCP.

- HTTP Get dal client (IP destinazione = IP SWA , porta destinazione = 3128 )

- Risposta HTTP dal proxy ( IP origine = SWA )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Da Image-Client a SWA, modalità HTTP Explicit

SWA e server Web

Il traffico di rete si verifica tra l'indirizzo IP del proxy e l'indirizzo IP del server Web.

Il traffico proveniente da SWA è destinato alla porta TCP 80 e ha origine da una porta casuale (non dalla porta proxy)

- Handshake TCP.

- HTTP Get dal proxy (IP destinazione = server Web, porta destinazione = 80 )

- Risposta HTTP dal server Web ( IP origine = server proxy )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine: da HTTP-SWA a Web server-Explicit-no cache

Di seguito è riportato un esempio di HTTP Get dal client

Immagine- Da client a SWA HTTP GET- Explicit

Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.

Immagine: tutto il traffico HTTP esplicito senza cache

Nota: ogni flusso di traffico è distinto da un colore diverso; il flusso dal client al SWA è di un colore e il flusso dal SWA al server Web è un altro.

Immagine - Flusso traffico HTTP esplicito - nessuna cache

Di seguito è riportato un esempio di log degli accessi:

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]

Traffico Con Dati Memorizzati Nella Cache

Rappresenta l'intero flusso di traffico dal client all'SWA, quando i dati si trovano nella cache SWA.

Immagine - Dati memorizzati nella cache HTTP Explicit

Nota: come si può vedere, il server Web restituisce la risposta HTTP 304: Cache not Modified (Cache non modificata). (nell'esempio, numero di pacchetto 1947)

Immagine - Flusso HTTP esplicito con cache

Di seguito è riportato un esempio di HTTP Response 304

Immagine - Risposta HTTP Explicit 304

Di seguito è riportato un esempio di log degli accessi:

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]

Traffico HTTP in distribuzione esplicita senza autenticazione

Client e SWA

Il traffico di rete passa tra l'indirizzo IP del client e l'indirizzo IP dell'interfaccia proxy SWA (di solito si tratta dell'interfaccia P1, ma può essere P2 o l'interfaccia di gestione, a seconda della configurazione del proxy).

Il traffico proveniente dal client è destinato alla porta TCP 80 o 3128 per l'interfaccia SWA (le porte proxy SWA predefinite sono TCP 80 e 3128, in questo esempio viene utilizzata la porta 3128)

- Handshake TCP.

- HTTP CONNECT dal client (IP destinazione = SWA, porta destinazione = 3128 )

- Risposta HTTP dal proxy ( IP origine = SWA )

- Client Hello con SNI dell'URL (Source IP = Client)

- Server Hello ( Source IP = SWA )

- Scambio chiave server (IP origine = SWA)

- Scambio chiave client ( IP origine = Client )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine- Client HTTPS su SWA-Explicit- Nessuna cache

Ecco i dettagli di Client Hello da Client a SWA, come si può vedere in SNI (Server Name Indication) è visibile l'URL del server Web che in questo esempio è www.example.com e il client ha annunciato 17 suite di cifratura:

Immagine - Hello del client HTTPS - Esplicito - Da client a SWA

Suggerimento: è possibile utilizzare questo filtro in Wireshark per cercare URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Di seguito è riportato un esempio di certificato inviato da SWA al client

Immagine - Certificato HTTPS - Esplicito - SWA al client

SWA e server Web

Il traffico di rete si verifica tra l'indirizzo IP del proxy e l'indirizzo IP del server Web.

Il traffico proveniente da SWA è destinato alla porta TCP 443 (non alla porta proxy)

- Handshake TCP.

- Client Hello (IP destinazione = server Web , porta destinazione = 443 )

- Server Hello ( IP origine = server Web )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine- HTTPS - Esplicita - SWA su webserver

Ecco i dettagli di Client Hello da SWA al server Web, come potete vedere SWA ha annunciato 12 suite di cifratura:

Immagine- Benvenuto client HTTPS - SWA al server Web- Nessuna cache

Nota: le suite di cifratura osservate qui differiscono dalle suite di cifratura in Client Hello da Client a SWA, in quanto l'SWA, configurato per decriptare questo traffico, utilizza le proprie cifrature.

Suggerimento: nello scambio di chiavi server da SWA a Web Server, viene visualizzato il certificato del server Web. Tuttavia, se un proxy upstream rileva una configurazione per il file SWA, viene visualizzato il relativo certificato anziché il certificato del server Web.

Di seguito è riportato un esempio di HTTP CONNECT dal client

Immagine - Connessione HTTP client

Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.

Immagine- HTTPS completo esplicito-Nessuna cache

Nota: ogni flusso di traffico è distinto da un colore diverso; il flusso dal client al SWA è di un colore e il flusso dal SWA al server Web è un altro.

Immagine - Flusso HTTPS - Esplicito - Nessuna cache

Di seguito è riportato un esempio di log degli accessi:

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]

Nota: come si può notare nella distribuzione trasparente per il traffico HTTPS, nei log degli accessi sono presenti 2 righe, la prima riga indica quando il traffico è crittografato ed è possibile visualizzare CONNECT e l'URL del server Web inizia con tunnel://. Se la decrittografia è abilitata nell'interfaccia SWA, la seconda riga contiene GET e l'intero URL inizia con HTTPS, ossia il traffico è stato decrittografato.

Traffico HTTPS pass-through

Se l'SWA è stato configurato in modo da passare attraverso il traffico, di seguito viene riportato il flusso complessivo:

Immagine - Pass-through HTTPS - esplicita - flusso

Di seguito è riportato un esempio di Client Hello da SWA al server Web:

Immagine - Pass-through HTTPS - Esplicita - SWA su Webserver - Salve client

Che è lo stesso del client Hello da client a SWA:

Immagine - Pass-through HTTPS - Esplicita - Da client a SWA - Salve client

Di seguito è riportato un esempio di accesso:

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]

Nota: come si può vedere, si tratta di una singola linea e l'azione è PASSTHRU.

Distribuzione trasparente

Traffico HTTP nella distribuzione trasparente senza autenticazione

Client e SWA

Il traffico di rete passa tra l'indirizzo IP del client e l'indirizzo IP del server Web.

Il traffico proveniente dal client è destinato alla porta TCP 80 (non alla porta proxy)

- Handshake TCP.

- HTTP Get dal client (IP destinazione = server Web, porta destinazione = 80 )

- Risposta HTTP dal proxy ( IP origine = server Web )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine - Da client a proxy - HTTP - Trasparente - Nessuna autenticazione

Di seguito è riportato un esempio di HTTP Get dal client

Immagine - Da client a proxy - HTTP - Trasparente - Nessuna autenticazione - Recupero HTTP client

SWA e server Web

Il traffico di rete si verifica tra l'indirizzo IP del proxy e l'indirizzo IP del server Web.

Il traffico proveniente da SWA è destinato alla porta TCP 80 (non alla porta proxy)

- Handshake TCP.

- HTTP Get dal proxy (IP destinazione = server Web, porta destinazione = 80 )

- Risposta HTTP dal server Web ( IP origine = server proxy )

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine - Proxy e server Web - HTTP - Trasparente - Nessuna autenticazione

Di seguito è riportato un esempio di HTTP Get da Proxy

Immagine - Proxy per server Web - HTTP - Trasparente - Nessuna autenticazione - Proxy HTTP Get

Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.

Immagine - Traffico totale - HTTP - Trasparente - Nessuna autenticazione

Nota: ogni flusso di traffico è distinto da un colore diverso; il flusso dal client al SWA è di un colore e il flusso dal SWA al server Web è un altro.

Immagine - Flusso HTTP WCCP

Di seguito è riportato un esempio di log degli accessi:

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]

Traffico Con Dati Memorizzati Nella Cache

Rappresenta l'intero flusso di traffico dal client all'SWA, quando i dati si trovano nella cache SWA.

Immagine - Memorizzata nella cache - Traffico totale - HTTP - Trasparente - Nessuna autenticazione

Nota: come si può vedere, il server Web restituisce la risposta HTTP 304: Cache not Modified (Cache non modificata). (nell'esempio, numero di pacchetto 27)

Di seguito è riportato un esempio di HTTP Response 304

Immagine nella cache - Risposta HTTP 304 - HTTP - Trasparente - Nessuna autenticazione

Di seguito è riportato un esempio di log degli accessi:

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]

Traffico HTTP nella distribuzione trasparente senza autenticazione

Client e SWA

Il traffico di rete passa tra l'indirizzo IP del client e l'indirizzo IP del server Web.

Il traffico proveniente dal client è destinato alla porta TCP 443 (non alla porta proxy)

- Handshake TCP.

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

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine - Da client a proxy - HTTP - Trasparente - Nessuna autenticazione

Di seguito sono riportati i dettagli di Client Hello da Client a SWA, come si può vedere in SNI (Server Name Indication) è possibile vedere l'URL del server Web che in questo esempio è www.example.com .

Image- Client Hello - Da client a proxy - Trasparente - Senza autenticazione

Suggerimento: è possibile utilizzare questo filtro in Wireshark per cercare URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Di seguito è riportato un esempio di Server Key Exchange

Immagine- Scambio chiave server - Da client a proxy - Trasparente - Nessuna autenticazione

Nota: come si può vedere, il Certificato è quello che è stato configurato in SWA come certificato di decrittografia.

SWA e server Web

Il traffico di rete si verifica tra l'indirizzo IP del proxy e l'indirizzo IP del server Web.

Il traffico proveniente da SWA è destinato alla porta TCP 443 (non alla porta proxy)

- Handshake TCP.

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

- Trasferimento dei dati

- Terminazione connessione TCP (handshake a 4 vie)

Immagine - Proxy per server Web - HTTP - Trasparente - Nessuna autenticazione

Ecco un esempio di Client Hello da SWA a Web Server

Image- Client Hello - Proxy per server Web - Trasparente - Nessuna autenticazione

Nota: le suite di cifratura osservate qui differiscono dalle suite di cifratura in Client Hello da Client a SWA, in quanto l'SWA, configurato per decriptare questo traffico, utilizza le proprie cifrature.

Suggerimento: nello scambio di chiavi server da SWA a Web Server, viene visualizzato il certificato del server Web. Tuttavia, se un proxy upstream rileva una configurazione per il file SWA, viene visualizzato il relativo certificato anziché il certificato del server Web.

Di seguito è riportato un esempio di log degli accessi:

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]

Nota: come si può notare nella distribuzione trasparente per il traffico HTTPS, nei log degli accessi sono presenti 2 righe, la prima riga indica quando il traffico è crittografato ed è possibile visualizzare TCP_CONNECT e l'indirizzo IP del server Web. Se la decrittografia è abilitata nell'interfaccia SWA, la seconda riga contiene GET e l'intero URL inizia con HTTPS, ossia il traffico è stato decrittografato e l'interfaccia SWA conosce l'URL.

Informazioni correlate

- Documentazione e supporto tecnico – Cisco Systems

- Configura parametro prestazioni nei log degli accessi - Cisco