Inconsistent policy behavior in transparent proxy mode

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

In a transparent access method, when configuring policy to block/allow based on request URL category, inconsistent policy behavior is encountered when a client makes a request to a secure [HTTPS] destination and the IP Address of the OCS is associated with a category that is blocked in the policy.

When using WSS Agent or Firewall/VPN transparently without explicit proxy (trans proxy), authenticated as DOM\user, requests to box.com are intermittently blocked.

Sometimes the requests are allowed as intended, but the behavior is inconsistent.

Environment

  Universal Policy Enforcement:  Management Center 

      - Policy configured to allow requests based on application name or request URL.

            - i.e.  Web Access Layer:  source: DOM\user  ->  application-name: Box  ->  action: Allow

      - Policy is configured in a rule below the above rule (in the same layer) to block requests based on the request URL category.

           - i.e. WebAccessLayer:  source: any  ->  request.url_category(file storage/sharing)  ->  action: Block

 

  On-Premise-Protection:  ProxySG Appliance - Explicit

      - Clients are aware of the proxy.

      - Connections to secure sites (HTTPS) will be preceded by a CONNECT request containing the destination URI from the browser.

            - i.e.  TCP 3-Way   - >   HTTP: [CONNECT www.example.com:443 HTTP/1.0]

      - ProxySG can enforce policy based on application-name/url, url.domain, url.category

            - Policy on the above conditions can be evaluated on the initial Client-In request, before making a request upstream to the OCS, because the URI is provided in plaintext.

            - This is specific to Explicit Proxy connections.

            - As opposed to transparent proxy connections, the explicit-proxy initially identifies the request-URI from the browser: www.example.com

 

  Remote-Protection: WSS Agent - Transparent

      - Clients are unaware of the proxy.

      - Connections to secure sites (HTTPS) will be negotiated as if the client is communicating directly with the OCS.

            - i.e.  TCP 3-Way   - >   Client Hello [sni: www.example.com]

      - The ProxySG (on-prem or in WSS) needs to wait for the client hello to attain a server-name/URL for the destination being requested.

            - This is required for transparent proxy connections because DNS is done by the client and the request will ingress the Proxy as if the Proxy was the OCS.

            - This initial connection would hit the proxies 443\TCP listener:  tcp://93.184.216.34:443/

            - As opposed to an explicit proxy connection, the transparent proxy initially identifies the OCS IP: 93.184.216.34

Cause

This issue can surface when the following conditions are met:

1. The request will ingress the Proxy (on-prem or in the WSS) transparently.
   
   
2. IP Address as resolved by the client, for the request URI, is associated with a category that is blocked in the policy.

            - i.e. tcp://x.x.x.x/ - > Category: File Storage/Sharing

            - The block rule does not have to be in a different layer, or above the allowed rule in the policy.  

In a transparent proxy environment, clients resolve DNS locally and request the server directly; they are not providing the proxy with the request URI /HTTP CONNECT after the TCP 3-Way.  Instead, the client will send the client hello upstream, as it normally would, to initiate the TLS handshake.

When the proxy receives this request, it needs to determine if it will be intercepting the traffic and if it will be decrypting the traffic.  

The connection will arrive at the proxy in the WSS via WSS Agent, transparently, as: tcp://x.x.x.x:443/  if the proxy is intercepting, it will send the request to the SSL proxy internally to handle TLS Negotiation on both sides of the transaction (server/client).  When this happens, the request will again ingress the proxy (at the SSL Proxy) as ssl://x.x.x.x:443/ and the proxy parses the client-hello and if allowed, initiate the TLS negotiation with the server upstream.  When the proxy receives the server certificate and is going to decrypt the traffic, it will send the request to its HTTPS service as:  https://www.example.com/  The proxy will inject the emulated-intermediary-CA cert in the chain and send that to the client as the server certificate.  

If the IP x.x.x.x is associated with a specific category, the proxy can rule a match on a block rule for that category and return an exception to the client, before the client-hello is received with the SNI of the server being requested.

Because the proxy does not (at this time in the transaction) have the client-hello/SNI, it is not able to match on the rule to allow the request-URL or request-application-name above the block rule in the same layer.  Because of this behavior does not matter where the block rule exists within the layer/policy as it will never receive the client-hello to rule and allow on the server name since it is already blocking on the request-URL-category of the IP.

The inconsistency in the case of Box.com was caused by some of the destinations' IPs not being associated with any category.  When those addresses were resolved/requested by clients, there was no match on the block as above.  When this occurs, the proxy will accommodate the connection until the client hello is received where it can more appropriately decide to allow or block.

Resolution

There are several ways to improve policy behavior:

1. If the server's IP address is associated with a category, you may submit a request via https://sitereview.bluecoat.com to have the category re-evaluated.
   
   
2. Move the category-based block rules from their existing layer, to an "SSL-Access-Layer" and modify the objects from "request.url_category()" to "server.certificate_category()"
   
   The rule above should only match a deny after it has associated a category to the common name on the cert (or in cases where the common name is not the URL -or- the URL is the IP address of the server, the first Subject Alternate Name of the server cert.  This would require a client-hello to have already been received from the client and we would again have more than enough information to enforce the allow.
   
   

3. Configure a regex rule/layer guard at the top of the Web Access Layer where the Category-Based Block exists, and make sure to Negate the destination object once created as follows:

   Add layer guard with Destination Request URL Object: Matching type - Regular Expression Match - with RegEx syntax:  ^(SSL|TCP)://  

NOTE: Make sure you Negate the Destination Request URL regex rule you create, the Action for your layer guard will be - (none)

The regex rule/layer guard above will match any handshake that will ingress as ssl://x.x.x.x:443/ or tcp://x.x.x.x:443/ and choose to neither block nor allow the request. This will allow the handshake to complete up to at least attaining a client-hello, before making a block/allow decision.

This policy would only apply to the initial negotiation of requests that ingress the proxy, once the proxy establishes SSL as the protocol and begins intercepting/decrypting, it will be able to appropriately decide on the same request, when it receives the client hello from downstream or the server certificate from upstream.

It would not result in clients being allowed to access sites when they should not be.  Instead, those same users will proceed to negotiate SSL/TLS before the proxy makes its ruling.  In the example environment above, DOM\user would then be permitted to negotiate SSL until the proxy attains either the SNI from the Client Hello, or the Server Certificate.

 

To describe it differently; a transparent-proxy environment should see up to 3 requests for each TLS/SSL connection from a client:

1. tcp://some-ip-addr x.x.x.x:443/    <- The initial connection i.e. client establishes TCP 3-way.  If we are TCP-Tunneling, we stop here.
2. ssl://some-website.com:443/    <- The proxy hands the request to the internal SSL-proxy i.e. Interception.  If we are intercepting but not decrypting we stop here.
3. https://some-website.com/       <-  The proxy is in the middle of the encrypted session. i.e. Decryption.

The regex rule recommended in step 3 above, will ensure the request is not blocked due to a [denied] category being associated with the request as it exists in step #1 and/or step #2.  This will permit the request to proceed through the proxy until we receive the client-hello or server certificate, and we would be able to evaluate and match on any actions respective to the URL, in step #3.