La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive il flusso di rete nella rete configurata dal proxy, in particolare per le appliance Web protette (SWA).
Cisco raccomanda la conoscenza dei seguenti argomenti:
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
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.
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:
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".
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.
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.
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.
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.
Client completato: il client invia un messaggio "Fine", crittografato con la chiave di sessione, per segnalare il completamento della parte client dell'handshake.
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 | 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. |
Codice | Dettagli |
200 |
Codice di risposta più comune. Ciò significa che la richiesta è stata completata senza alcun problema. |
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, |
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. |
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. |
Ecco...
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)
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)
Di seguito è riportato un esempio di HTTP Get dal client
Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.
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.
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]
Rappresenta l'intero flusso di traffico dal client all'SWA, quando i dati si trovano nella cache SWA.
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)
Di seguito è riportato un esempio di HTTP Response 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]
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)
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:
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
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)
Ecco i dettagli di Client Hello da SWA al server Web, come potete vedere SWA ha annunciato 12 suite di cifratura:
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
Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.
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.
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.
Se l'SWA è stato configurato in modo da passare attraverso il traffico, di seguito viene riportato il flusso complessivo:
Di seguito è riportato un esempio di Client Hello da SWA al server Web:
Che è lo stesso del client Hello da client a SWA:
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.
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)
Di seguito è riportato un esempio di HTTP Get dal client
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)
Di seguito è riportato un esempio di HTTP Get da Proxy
Questo rappresenta l'intero flusso di traffico dal client al dispositivo SWA, quindi al server Web e infine di nuovo al client.
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.
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]
Rappresenta l'intero flusso di traffico dal client all'SWA, quando i dati si trovano nella cache SWA.
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
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]
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)
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 .
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
Nota: come si può vedere, il Certificato è quello che è stato configurato in SWA come certificato di decrittografia.
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)
Ecco un esempio di Client Hello da SWA a Web Server
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.
Revisione | Data di pubblicazione | Commenti |
---|---|---|
1.0 |
13-May-2024 |
Versione iniziale |