Understand Packet Flow in Secure Web Appliance

Available Languages

Download Options

PDF (7.4 MB)
View with Adobe Reader on a variety of devices
ePub (7.4 MB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (4.7 MB)
View on Kindle device or Kindle app on multiple devices

Updated:May 8, 2024

Document ID:221980

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

This document describes the network flow in Proxy configured network, specifically focused on Secure Web Appliance (SWA).

Prerequisites

Requirements

Cisco recommends that you have knowledge of these topics:

Basic TCP/IP concepts.
Basic knowledge of Proxy setup.
Basic knowledge of Authentication mechanism used in environment with Proxy.

Abbreviations used is this articles are:

TCP: Transmission Control Protocol

UDP: User Datagram Protocol

IP: Internet Protocol

GRE: Generic Routing Encapsulation

HTTP: Hypertext Transfer Protocol.

HTTPS: Hypertext Transfer Protocol Secure.

URL: Uniform Resource Locator

TLS: Transport Layer Security

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.

Deferent Typs of Proxy Deployment

TLS Handshake

A TLS handshake in HTTPS occurs when a client and server communicate over the Internet, providing a secure connection. The process maintains privacy and data integrity between two communicating applications. It operates through a series of steps where the client and server agree on encryption standards and codes for all subsequent transmissions. The handshake aims to deter any unauthorized access or manipulation by third parties. It also authenticates the identities of the communicating parties to eliminate impersonation. This process is crucial in HTTPS as it ensures that data remains secure while in transit.

Here are the steps of a TLS handshake:

Client Hello: The client initiates the handshake process with a hello message. This message contains the client TLS version, supported cipher suites, and a random byte string known as the "client random".
Server Hello: The server responds with a hello message. This message includes the server chosen TLS version, selected cipher suite, a random byte string known as the "server random", and the server digital certificate. If necessary, the server also requests the client digital certificate for mutual authentication.
Client verifies the server certificate: The client checks the server digital certificate with the certificate authority that issued it. This assures the client that it is communicating with the legitimate server.
Pre-master Secret: The client sends a random byte string, known as the "pre-master secret," which contributes to the creation of the session keys. The client encrypts this pre-master secret with the server public key, so only the server can decrypt it with its private key.
Master Secret: Both the client and server use the pre-master secret and the random byte strings from the hello messages to independently compute the same "master secret." This shared secret is the basis for generating the session keys.
Client Finished: The client sends a "Finished" message, encrypted with the session key, to signal the completion of the client part of the handshake.
Server Finished: The server sends a "Finished" message, also encrypted with the session key, to signal the completion of the server part of the handshake.

HTTP Response Code

1xx : Informational

Code

Details

100 Continue

Typically seen in regards to the ICAP protocol. This is an informational response that let the client know that it can continue to send data. In regards to ICAP services (such as virus scanning), the server can only want to see first x amount of bytes. When it is done scanning the first set of bytes and did not detect a virus, it sends a 100 Continue to let the client know to send the rest of the object.

2xx: Successful

Code	Details
200 OK	The most common response code. This signifies that the request is successful without any problems.

3xx: Redirection

Code	Details
301 Permanent Redirection	This is a Permanent redirection, you can see this code when you are redirecting to www sub-domain.
302 Temporary Redirection	This is a temporary redirection. The client is instructed to make a new request for the object specified in the Location: header.
304 Not Modified	This is in response to a GIMS (GET If-modified-since). This is literally a standard HTTP GET that includes the header If-modified-since: <date>. This header tells the server that the client has a copy of the requested object in it local cache and included is the date the object was fetched. If the object has been modified since that date, the server responds with a 200 OK and a fresh copy of the object. If the object has not changed since the fetched date, the server sends back a 304 Not Modified response.
307 Authentication Redirection	This is seen mostly, in transparent Proxy Deployment, when the Proxy server is configured to authenticate the request and redirects the request to another URL to authenticate the user,

4xx codes: Client Error

Code	Details
400 Bad Request	This suggests an issue with the HTTP request, as it does not comply with the proper syntax. Possible reasons could include multiple headers on a single line, spaces within a header, or the lack of HTTP/1.1 in the URI, among others. For the correct syntax, please consult RFC 2616.
401 Unauthorized Web Server Authentication Required	Access to the requested object necessitates authentication. The 401 code is utilized for authentication with a target web server. When the SWA operates in transparent mode and authentication is enabled on the proxy, it returns a 401 to the client, since the appliance presents itself as if it were the OCS (origin content server). The methods of authentication that can be used are detailed in a 'www-authenticate:' HTTP response header. This informs the client whether the server is requesting NTLM, basic, or other forms of authentication.
403 Denied	The client cannot access the requested object. A variety of reasons could lead a server to deny object access. The server typically provides a cause description within the HTTP data or HTML response.
404 Not Found	The requested object does not exist on the server.
407 Proxy Authentication Required	This is the same as a 401, except that it is specifically for authentication to a proxy not the OCS. This is sent only if the request was sent explicitly to the proxy. A 407 cannot be sent to a client while SWA is configured as transparent proxy, as the client does not know the proxy exists. If this is the case, the client most likely FIN or RST the TCP socket.

5xx: Server Error

Code	Details
501 Internal Server Error	Generic Web server failure.
502 Bad Gateway	Occurs when a server acting as a gateway or proxy receives an invalid response from an inbound server. It signals that the gateway has received an inappropriate response from the upstream or origin server.
503 Service Unavailable	Signifies that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance. It implies that the server is temporarily out of service but can be available again after some time.
504 Gateway Timeout	Indicates that a client or proxy, did not receive a timely response from Web server it attempted to access to load the web page or fulfill another request by the browser. This often implies that the upstream server is down.

Explicit Deployment

Here ....

HTTP Traffic in Explicit Deployment Without Authentication

Client and SWA

Network traffic transpires between the IP address of the client and the IP address of the SWA proxy interface (usually it is P1 interface, but it can be P2 or Management interface, depends on Proxy configuration).

The traffic from client is destined to TCP port 80 or 3128 to the SWA (Default SWA proxy ports are TCP 80 and 3128, in this example we use port 3128)

TCP Handshake.
HTTP Get from Client (Destination IP = SWA IP , Destination Port = 3128 )
HTTP response from Proxy ( Source IP = SWA )
Data transfer
TCP connection termination (4-Way Handshake)

Image-Client to SWA, HTTP Explicit mode

SWA and Web Server

The network traffic occurs between the IP address of the Proxy and the IP address of the web server.

The traffic from SWA is destined to TCP port 80 and sourced with a random port (Not the Proxy Port)

TCP Handshake.
HTTP Get from Proxy (Destination IP = Web server , Destination Port = 80 )
HTTP response from Web Server ( Source IP = Proxy server )
Data transfer
TCP connection termination (4-Way Handshake)

Image- HTTP-SWA to web server-Explicit-no cache

Here is sample of HTTP Get from Client

Image- Client to SWA HTTP GET- Explicit

This represents the entire flow of traffic from the client to the SWA, then to the web server, and finally back to the client.

Image- All traffic HTTP Explicit-no cache

Note: Each stream of traffic is distinguished by a different color; the flow from the client to the SWA is one color, and the flow from the SWA to the web server is another.

Image- Traffic Flow HTTP Explicit - no cache

Here is a sample of 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]

Traffic With Cached Data

This represents the entire flow of traffic from the client to the SWA, when the data is in SWA Cache.

Image- HTTP Explicit Cached data

Note: As you can see the Web Server returns HTTP response 304: Cache not Modified. (in this Example, Packet number 1947)

Image- Flow HTTP Explicit with cache

Here is a sample of HTTP Response 304

Image- HTTP Explicit 304 response

Here is a sample of 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]

HTTPs Traffic in Explicit Deployment Without Authentication

Client and SWA

Network traffic transpires between the IP address of the client and the IP address of the SWA proxy interface ( usually it is P1 interface, but it can be P2 or Management interface, depends on Proxy configuration).

The traffic from client is destined to TCP port 80 or 3128 to the SWA (Default SWA proxy ports are TCP 80 and 3128, in this example we use port 3128)

TCP Handshake.
HTTP CONNECT from Client (Destination IP = SWA , Destination Port = 3128 )
HTTP response from Proxy ( Source IP = SWA )
Client Hello with SNI of the URL (Source IP = Client)
Server Hello ( Source IP = SWA )
Server Key Exchange ( Source IP = SWA)
Client Key Exchange ( Source IP = Client )
Data transfer
TCP connection termination (4-Way Handshake)

Image- HTTPS Client to SWA-Explicit- No Cache

Here is details of Client Hello from Client to SWA, as you can see in the Server Name Indication (SNI) the URL of the web server can be seen which in this example, is www.example.com and client advertised 17 Cipher Suites:

Image- HTTPS Client hello - Explicit - Client to SWA

Tip: You can use this filter in Wireshark to search for URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Here is a sample of certificate which SWA sent to Client

Image- HTTPS certificate - Explicit - SWA to client

SWA and Web Server

The network traffic occurs between the IP address of the Proxy and the IP address of the web server.

The traffic from SWA is destined to TCP port 443 ( Not the Proxy Port)

TCP Handshake.
Client Hello (Destination IP = Web server , Destination Port = 443 )
Server Hello ( Source IP = Web server )
Data transfer
TCP connection termination (4-Way Handshake)

Image- HTTPS - Explicit - SWA to webserver

Here is the details of Client Hello from SWA to web server, as you can see SWA advertised 12 Cipher Suites:

Image- HTTPS Client Hello - SWA to Web server- No Chache

Note: The Cipher Suites observed here differ from the Cipher Suites in the Client Hello from Client to SWA, as the SWA, configured to decrypt this traffic, utilizes its own Ciphers.

Tip: In the Server Key Exchange from SWA to Web Server, the Web Server certificate appears. However, if an Upstream Proxy finds configuration for your SWA, its certificate shows up instead of the Web Server certificate.

Here is sample of HTTP CONNECT from Client

Image- Client HTTP Connect

This represents the entire flow of traffic from the client to the SWA, then to the web server, and finally back to the client.

Image- Full HTTPS explicit-No Cache

Note: Each stream of traffic is distinguished by a different color; the flow from the client to the SWA is one color, and the flow from the SWA to the web server is another.

Image- HTTPS Flow- Explicit - No Cache

Here is a sample of 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]

Note: As you can see in transparent deployment for HTTPS traffic there are 2 lines in Accesslogs, the first line is when the traffic is Encrypted and you can see CONNECT and the URL of the Web Server starts with tunnel://. If Decryption is enabled in SWA, the second line contains GET and the whole URL starts with HTTPS, which means the traffic has been decrypted.

Passthrough HTTPS traffic

If you configured your SWA to passthrough the traffic, here is the overall flow:

Image- HTTPS Passthrough - Explicit - Flow

Here is the sample of Client Hello from SWA to Web server:

Image- HTTPS Passthrough - Explicit - SWA to Webserver - Client hello

Which is same as the Client Hello from Client to SWA:

Image- HTTPS Passthrough - Explicit - Client to SWA - Client hello

Here is a sample 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]

Note: As you can see, it is just a single line and the action is PASSTHRU.

Transparent Deployment

HTTP Traffic in Transparent Deployment Without Authentication

Client and SWA

Network traffic transpires between the IP address of the client and the IP address of the web server.

The traffic from client is destined to TCP port 80 ( Not the Proxy Port)

TCP Handshake.
HTTP Get from Client (Destination IP = Web server , Destination Port = 80 )
HTTP response from Proxy ( Source IP = Web server )
Data transfer
TCP connection termination (4-Way Handshake)

Image- Client to Proxy - HTTP - Transparent - No Auth

Here is sample of HTTP Get from Client

Image- Client to Proxy - HTTP - Transparent - No Auth - Client HTTP Get

SWA and Web Server

The network traffic occurs between the IP address of the Proxy and the IP address of the web server.

The traffic from SWA is destined to TCP port 80 ( Not the Proxy Port)

TCP Handshake.
HTTP Get from Proxy (Destination IP = Web server , Destination Port = 80 )
HTTP response from Web Server ( Source IP = Proxy server )
Data transfer
TCP connection termination (4-Way Handshake)

Image- Proxy and Web Server - HTTP - Transparent - No Auth

Here is sample of HTTP Get from Proxy

Image- Proxy to Web Server - HTTP - Transparent - No Auth - Proxy HTTP Get

This represents the entire flow of traffic from the client to the SWA, then to the web server, and finally back to the client.

Image- Total Traffic - HTTP - Transparent - No Auth

Note: Each stream of traffic is distinguished by a different color; the flow from the client to the SWA is one color, and the flow from the SWA to the web server is another.

Image- WCCP HTTP Flow

Here is a sample of 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]

Traffic With Cached Data

This represents the entire flow of traffic from the client to the SWA, when the data is in SWA Cache.

Image- Cached- Total Traffic - HTTP - Transparent - No Auth

Note: As you can see the Web Server returns HTTP response 304: Cache not Modified. (in this Example, Packet number 27)

Here is a sample of HTTP Response 304

Image- Cached - HTTP response 304 - HTTP - Transparent - No Auth

Here is a sample of 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]

HTTPs Traffic in Transparent Deployment Without Authentication

Client and SWA

Network traffic transpires between the IP address of the client and the IP address of the web server.

The traffic from client is destined to TCP port 443 ( Not the Proxy Port)

TCP Handshake.
TLS Handshake Client Hello - Server Hello - Server Key Exchange - Client Key Exchange
Data transfer
TCP connection termination (4-Way Handshake)

Image- Client to Proxy - HTTPs - Transparent - No Auth

Here is details of Client Hello from Client to SWA, as you can see in the Server Name Indication (SNI) the URL of the webserver can be seen which in this example, is www.example.com .

Image- Client Hello - Client to Proxy - Transparent - No Auth

Tip: You can use this filter in Wireshark to search for URL/SNI : tls.handshake.extensions_server_name == "www.example.com"

Here is a sample of Server Key Exchange

Image- Server Key Exchange - Client to Proxy - Transparent - No Auth

Note: As you can see the Certificate is the one which was configured in SWA as Decryption certificate.

SWA and Web Server

The network traffic occurs between the IP address of the Proxy and the IP address of the web server.

The traffic from SWA is destined to TCP port 443 ( Not the Proxy Port)

TCP Handshake.
TLS Handshake Client Hello - Server Hello - Server Key Exchange - Client Key Exchange
Data transfer
TCP connection termination (4-Way Handshake)

Image- Proxy to Web Server - HTTPs - Transparent - No Auth

Here is a sample of Client Hello from SWA to Web Server

Image- Client Hello - Proxy to Web Server - Transparent - No Auth

Note: The Cipher Suites observed here differ from the Cipher Suites in the Client Hello from Client to SWA, as the SWA, configured to decrypt this traffic, utilizes its own Ciphers.

Here is a sample of 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]

Note: As you can see in transparent deployment for HTTPS traffic there are 2 lines in Accesslogs, the first line is when the traffic is Encrypted and you can see TCP_CONNECT and the IP address of the Web Server. If Decryption is enabled in SWA, the second line contains GET and the whole URL starts with HTTPS, which means the traffic has been decrypted and SWA knows the URL.

Related Information

Revision History

Revision	Publish Date	Comments
1.0	13-May-2024	Initial Release

Contributed by Cisco Engineers

Amirhossein Mojarrad
Technical Consulting Engineer

Was this Document Helpful?

Feedback

Contact Cisco

Open a Support Case
(Requires a Cisco Service Contract)

This Document Applies to These Products

Secure Web Appliance

Understand Packet Flow in Secure Web Appliance

Available Languages

Download Options

Bias-Free Language

Contents

Introduction

Prerequisites

Requirements

Components Used

Deferent Typs of Proxy Deployment

TLS Handshake

HTTP Response Code

1xx : Informational

2xx: Successful

3xx: Redirection

4xx codes: Client Error

5xx: Server Error

Explicit Deployment

HTTP Traffic in Explicit Deployment Without Authentication

Client and SWA

SWA and Web Server

Traffic With Cached Data

HTTPs Traffic in Explicit Deployment Without Authentication

Client and SWA

SWA and Web Server

Passthrough HTTPS traffic

Transparent Deployment

HTTP Traffic in Transparent Deployment Without Authentication

Client and SWA

SWA and Web Server

Traffic With Cached Data

HTTPs Traffic in Transparent Deployment Without Authentication

Client and SWA

SWA and Web Server

Related Information

Revision History

Contributed by Cisco Engineers

Was this Document Helpful?

Contact Cisco

This Document Applies to These Products