Pac files with WSS Agent (WSSA)

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

What are the best practices for pac file usage (explicitly proxied traffic) with WSSA?

Resolution

The recommended "best practice" is to deploy the WSS Agent (WSSA) in transparent mode with no pac file (no client proxy configuration).

Transparent deployment of WSSA is preferred and is easier to troubleshoot issues related to routing.  One major concern with explicitly proxied traffic is that pac files leverage the non-secure HTTP proxy protocol.  To protect against spoofing of your proxy server, you can use WSSA transparent interception on insecure networks (by NOT using a pac file in your client configurations). 

A pac file is an older style security practice that complicates configurations for customers when they want to use modern cloud security. 

One complication is that you must administer the pac file to split traffic between a local on-premise proxy server, and have other traffic route to cloud proxies.  The experience with the CloudSWG service is optimized when all WSSA traffic is transparently sent to the CloudSWG service.

Using a pac file with WSSA causes complexity, increases administrative burdens, and makes troubleshooting issues more difficult and time consuming.

If a pac file for explicitly proxied traffic is required (NOT recommended), then below are important considerations: 

• For traffic that should go to the CloudSWG service via WSSA, then the pac file should use the "DIRECT" statement (not "ep.threatpulse.net"):
  ep.threatpulse.net
  
  
• The host "ep.threatpulse.net" resolves to a special service-listener address (199.19.250.205) that resides on every CloudSWG data-pod and should NOT be a "catch all" for explicitly proxied traffic.
  
  
• The WSSA driver will intercept traffic that is sent "DIRECT" from the pac file.

Configure the pac file in the following way to have WSSA intercept traffic that you want sent to the CloudSWG service: 

EXAMPLE (use this):
  return "DIRECT";

EXAMPLE (do not use):
  return "PROXY ep.threatpulse.net:80";

Traffic that is sent "DIRECT" in the pac file will be intercepted by the WSSA driver.  Attempting to use "ep.threatpulse.net" (instead of "DIRECT") can cause unexpected behavior and performance issues.

Disadvantages of using a pac file with WSSA:
- Security risk: pac files leverage the non-secure HTTP proxy protocol
- More difficult to troubleshoot due to increased complexity
- More complex to bypass sites (must keep bypassed sites synced in both pac file and ATM/WSSA bypass lists)
- More complex and time consuming to administer

Advantages of using a transparent deployment (no pac file) with WSSA:
- More secure: no risk of using the non-secure HTTP protocol
- Easier to troubleshoot issues (both routing and bypasses)
- Easier to bypass sites (don't have to sync bypass domains between pac file and ATM/WSSA bypass lists)
- Less complex to administer

Additional Information

Additional problems if the pac file attempts to PROXY to: "ep.threatpulse.net"

The WSSA "fail mode" capability cannot function correctly when using a pac file and trying to PROXY to "ep.threatpulse.net" because this host is a "special use" host for the CloudSWG service and this host is always tunneled (allowed). 

Traffic to this host will fail on the WSSA tunnel connection if the tunnel is not up.  This scenario prevents the WSSA client from successfully "failing open" if you are trying to proxy to ep.threatpulse.net.