ProxySG Denied SSL Request Behavior Explained

book

Article ID: 169370

calendar_today

Updated On:

Products

ProxySG Software - SGOS

Issue/Introduction

The following tests show exactly what happens on different connect requests using different settings and policy in the proxy to deny the requests.
 

Test 1 – Force deny with SSL interception

 
This test was performed with the following rule, url.domain="hangouts.google.com" force_deny. When you have SSL interception enabled and consequently detect protocol, you will always see the proxy making a request upstream and 200 responses sent back.

The following Wireshark screenshot depicts the connect request from client machine to proxy:



Here you can see a connect request being made and a 200 response. This is normal behaviour.
 
The following Wireshark screenshot depicts the connect request from proxy to OCS:



This is normal behavior when we need to inject some form of exception page because the proxy must contact the OCS to retrieve the certificate so that we can decode the SSL and inject a page to be seen on the browser.
 

Test 2 – Force deny with no SSL interception but with detect protocol

This test was again with a simple rule of force deny google hangouts but with no SSL interception and detect protocol enabled on the HTTP explicit service.
When making the request to hangouts.google.com you see the following in the packet capture from client to proxy:



The following depicts proxy to OCS:


 
As you can see, the proxy again sends the request upstream to the OCS because we need to obtain the certificate to successfully inject an exception page. Such as the following:


 

Test 3 – Deny with no SSL interception and no detect protocol

 
In this test there was a simple deny rule with no detect protocol as a global setting on the HTTP explicit service, url.domain="hangouts.google.com" deny.
If you turn off detect protocol with no SSL interception, then you will see the following:



There is no exception page only the following is displayed the end user:


 
With this setup in place, the user does not see an exception page, only a generic browser error message.
 

Test 4 – Deny rule in Web Request Layer that also adds the access_server(no) action

During this test, again there was a simple rule of, url.domain="hangouts.google.com" Deny access_server(no).
The following image depicts the results from proxy to client:


 
The following image depicts the results from proxy to OCS:


 
Again, you can see that the proxy contacts the OCS to retrieve the certificate to effectively decode the SSL stream so that it can inject an exception page to display to the user.
This is how the proxy works based upon the policy outlined. To serve an exception page, you must have detect protocol enabled, this will mean that the proxy must contact the OCS to retrieve the certificate so that it can intercept and inject the exception page.SSL certificates have what is called a Key Pair, this key pair is made up of a Public Key and a Private Key. These keys work together to establish an encrypted connection and are what is needed to successfully intercept the traffic.

 

Resolution

For a deny rule, to successfully inject an exception page, you must have detect protocol enabled. Without this, the proxy will not contact the OCS and so will not retrieve the certificate which contains the key pair and so we can not intercept the traffic to inject the exception page.
The proxy can block the request without contacting the OCS but will not be able to inject an exception page, the user will only see a generic browser message.

 

Attachments