Connection to a remote server (OCS via Cloud SWG) is not working when TLS interception is disabled

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

The customer is managing web-application traffic via Cloud SWG and the remote server is allowed access to a specific site.

Access to the server was working until a policy change that caused the traffic to no longer be TLS intercepted.

Why is this happening and what can or should be done to avoid any repeat in the future?

Environment

Cloud SWG with a client Trust Store with a limited count of root CA (not a full browser or machine with a default trust store).

 

Cause

After the policy change the connectivity issue was caused by the server configuration as it was setup with the Cloud CA in its trust store but did not contain destination server Certificate Authority at the top of the server trust chain (the root CA).

This caused the TLS negotiation to start between the client and OCS but the client was rejecting the connection as the root CA was not trusted, the trust chain pointed to a Certificate Authority not known or trusted by the client.

Resolution

Limiting the client to only accept connection to the destination server if the TLS session is intercepted by Broadcom Cloud SWG is a single point of failure that is limiting the possibilities to work around policy issues or limitations as we have seen in this case.

We always recommend to ensure access to the remote server is allowed in this following order:

1. Without Broadcom Cloud SWG TLS interception: the TLS session is negotiated between the client and server directly (the traffic is still routed via Cloud SWG infrastructure)
2. With Broadcom Cloud SWG TLS interception: the TLS session is negotiated between the client and Cloud SWG proxy

This ensure that if anything unplanned or unforeseen happens to your policy and TLS is disabled the access to the service remains available whilst troubleshoot or policy change is made to restore the TLS interception.