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 to a category that is blocked in policy.
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 configured in a rule below the above rule (in the same layer) to block requests based on 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 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 Unified 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://126.96.36.199:443/
- As opposed to an explicit proxy connection, the transparent-proxy initially identifies the OCS IP: 188.8.131.52
When using Unified Agent and authenticated as DOM\user, requests to Box.com are intermittently blocked.
Sometimes the requests are allowed as intended, but the behavior is inconsistent.
1.) 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 to a category that is blocked in 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 allow rule in policy.
In a transparent-proxy environment clients are resolving DNS locally and requesting 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 furthermore if it will be decrypting the traffic.
The connection will arrive at the proxy in the WSS via Unified 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 to 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, it does not matter where the block rule exists within the layer/policy as it will never receive the client-hello to rule an 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 destination IP's not being associated to 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.
1.) If the IP address of the server is associated to a category, you may submit a request via https://sitereview.bluecoat.com to have the category removed.
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 Cetagory-Based Block exists, as such:
- Destination Object: REGEX: ^(SSL|TCP):// Action: None
The regex in the rule above will match any handshake that will ingress as ssl://x.x.x.x:443/ or tcp://x.x.x.x:443/ and chose 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 make a decision on the same request, when it receives the client hello from downstream or the server certificate from upstream. This 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 in a different way; a transparent-proxy environment should see up to 3 requests for each TLS/SSL connection from a client:
1.) tcp://some-website.com:443/ <- this is reflected upon the initial connection i.e. client establishes TCP 3-way. If we are TCP-Tunneling, we stop here.
2.) ssl://some-website.com:443/ <- this is reflected when we hand 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/ <- this is reflected when we are in the middle of the encrypted session. i.e. Decryption.
The regex rule recommended instep 3 above, will ensure the request is not blocked due to a [denied] category being associated to 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.
Subscribing will provide email updates when this Article is updated. Login is required to Subscribe
Thanks for your feedback. Let us know if you have additional comments below. (requires login)
This will clear the history and restart the chat.