Traffic into WSS Agent tunnel visible before SAML authentication completes

Products

• Cloud Secure Web Gateway - Cloud SWG

Issue/Introduction

When enabling SAML authentication with the WSS Agent, no traffic is allowed into the tunnel until the SAML authentication succeeds per the documented SAML flow.

Most users confirmed this scenario by going to a browser on host before the authentication credentials were entered.

Some users reported being able to access certain sites (most sites returned block pages) despite not completing the SAML authentication.

Users reporting issues had PAC file downloaded pointing users to Proxy server on 199.19.250.205:80.

Why are we allowing traffic into Cloud SWG from the Agent before user has fully authenticated with SAML?

Environment

WSS Agent.

SAML Authentication.

Cloud SWG.

Cause

saml.threatpulse.net (199.19.250.205) whitelisted by the agent and all traffic destined for this IP address is allowed through by default.

Resolution

Either avoid using PAC files to send traffic into ep.threatpulse.net:80 (199.19.250.205), or make sure policy entry exists only allowing authenticated traffic.

Additional Information

WSS Agent, as per the above referenced documentation, only allows unauthenticated user requests to pod.threatpulse.com and saml.threatpulse.net by default with SAML authentication.

saml.threatpulse.com traffic is sent on TCP 8443 and resolves to 199.19.250.205.

When WSS Agent host has a proxy enabled and that proxy is configured to sends traffic into ep.threatpulse.net:80 (199.19.250.205), this matches the saml.threatpulse.com IP address and is allowed through despite being on TCP 80, and not 8443 (SAML traffic)

WSS Agent cannot differentiate between TCP ports as it works at layer 3, and hence cannot differentiate between traffic destined to SAML service and the proxy.