SSL Interception Flow

[ProxyAdmin TRG]

1. How does the SSL interception works on the proxysg? How does encryption/decryption happen for the requests coming into Proxy?

 

2. If any of the HTTP/HTTPS requests coming into proxy does not require SSL interception, how does the proxy decrypt that and process further?

 

3. How does the proxy send the traffic to CAS/MA? Encrypted or Unencrypted? If Encrypted, how does CAS/MA decrypt it and inspect it ?

[Klaus Klinge]

for 1 - The Proxy pretends to be the requested webserver an makes all Handshakes with the Client, so the Browser believes that it communicates directly with the server. 
It is a little more complicated: The Browser "tells" the proxy, that he wanted to communicate with e.g. https://www.nasa.gov. The Proxy build up a connection with the original Webserver an get's the original SSL-Cert. Then the proxy created a new certificate using as much informations as possible from the original certificate and shows this to the Browser. While the original SSL-cert comes from Let's Encrypt - is the "faked" Cert signed by the SSL-Interception Certificate of the proxy. 
So normaly the Browser would show a warning, that he didn't trust the cert the proxy shows him, but because all browsers in the company trust the SSL interception certificate, they accept the new certificate without complaining.

for 2. - if there is a rule that specifies for a connection (a scource, or a URL, or ...) that no SSL interception is made, then the proxy looks into the connection and sees how the browser and the web server do the TCP and SSL handshake. 
The proxy can check whether, for example, it thinks the cipher used is good or whether it trusts the SSL certificate of the web server itself. In this mode, the proxy could, for example, prohibit communication with a web server that provides a self-sign certificate.
After that, it's over - the proxy cannot see what data is going over the encrypted connection. It only transports the data from A to B and the responses from B to A.  So in this case there is nothing the proxy could send to a CAS. No SSL-Interception means automaticly no Virus-scanning.

The next level goes even further: A rule with "Disable SSL Detection" means that the proxy only transports the data and does not scan the SSL encryption between the browser and the web server.

3. the CAS/MA must be set up on the proxy - this determines whether ICAP or S-ICAP (Secure ICAP) is used. 
S-ICAP can be thought of as the CAS being a web server with an SSL certificate to which the proxy uploads a file.
The disadvantage is that this encryption also takes a very small amount of time and therefore the latency with S-ICAP is somewhat greater than with ICAP. However, the advantage of S-ICAP is that the data is secure on the way from the proxy to the CAS. 
Imagine you are surfing a webmailer and receive an email with a very personal file attached. The connection to the webmailer is protected with https, the proxy makes an SSL interception and now sends this file to the CAS and you have (perhaps out of laziness) only set up ICAP. The file is then sent to CAS unencrypted. If someone from the network team has now set up a mirror port on the path between the proxy and CAS and captures the data traffic (which you cannot notice) then the packet capture contains the personal file. And you don't want that.

[ProxyAdmin TRG]

Hi Klaus, 

 

Thanks for the update.

 

So for the requests going into CAS/MA from Proxy, it depends on the ICAP service.

 

For the requests which are configured not to go through SSL interception, what exactly does the proxy does to pass that connection?

[Klaus Klinge]

1. Proxy get the request from the Browser - TCP-Handshake and Browser delivers the requested URL
2. Proxy makes DNS and opens a connection to the Webserver and makes a TCP Handshake
3. Proxy is validating the ruleset (is the access allowed) - Allowed yes, but SSL-Interception: no
4. Proxy transfers the Client-Info Part and checks if there are not allowed TLS-Modes (1.0, 1.1) and weak ciphers. 
5. Proxy gets the Server-SSL-Handshake and checks the Certificate (e.g. Self-sign cert)
6. Proxy sends the SSL-Handshake to the client 
7. At this point the Proxy only delivers the Server Data to the Client and the Client Data (requests) to the Server. 

This is the basic what happens. 

I didn't mention: 
- Web Request Layers that maybe forbid to connect the Server before checking the ruleset for an Allow
- Http2.0 controls
- User Authentication
- Web-Filter and Threat Risk.
- Certificate Chaching
- "normal" caching is offline, because SSL-Interception is switched of in this example
- and "SSL-Intercept-on Error" is assumed to be also not used here - so in Case the Proxy don't allow e.g. an expired SSL-Cert/Self-Sign-Cert -> the proxy can't deliver an exception to the Client. So the user will only see an Browser Errormessage, but he can't see the reason.
- DNS could also be part of the Proxy-Ruleset 
- And there may be also a check for URL-category and Threat-Risk on the SSL-Certificate from the Webserver.