Netskope: Cloud Forward Proxy and Inline TLS Decryption

The generic SSL forward proxy article describes outbound TLS interception performed by a proxy at the network edge. Netskope does the same job, but relocates the proxy: instead of an appliance in the data center, the interception happens in Netskope's cloud, the NewEdge global network of data planes, and traffic is steered there from wherever the user is. That single architectural shift is what makes it a Secure Service Edge (SSE) product rather than a box, and it changes how the pieces of the generic model are arranged without changing the mechanics of interception itself.

Where the proxy lives: steering to the cloud

Because the proxy is not on the local network, the first problem is getting traffic to it. Netskope calls this steering, and its reference architecture offers several methods for the forward-proxy (outbound) case: the Netskope One Client on managed endpoints (a lightweight agent that tunnels cloud and web traffic to the platform, with all proxying and security done in the cloud); GRE or IPsec tunnels from an on-premises egress device (with at least two tunnels to different NewEdge data planes recommended for resilience); and the Cloud Explicit Proxy, steered by a PAC file, for devices that cannot run the client. When explicit-proxy traffic is carried inside a tunnel, Netskope calls the method Explicit Proxy over Tunnel (EPoT). The common thread is that all of these deliver the user's web and cloud traffic to a NewEdge data plane, which is where the actual forward proxy sits.

Interception, unchanged in the middle

Once traffic reaches NewEdge, the interception is the generic model exactly. The Next Gen Secure Web Gateway terminates the user's TLS, opens its own session to the destination, decrypts, inspects, applies policy (web filtering, threat protection, DLP, inline CASB controls), and re-encrypts. And it depends on the same trust anchor every interception depends on: the Netskope root CA must be trusted on the endpoints, or clients will reject the re-signed certificates. Netskope's own documentation is explicit that user SAML authentication and SSL inspection are possible only if the Netskope root and intermediate certificate bundle can be installed on the endpoints. For remote users on the Cloud Explicit Proxy, the root certificate is downloaded and installed per device. This is the cloud-hosted version of the "install the proxy's CA on managed devices" requirement from the generic article.

Identifying the user: SAML in the forward-proxy path

A forward proxy needs to know who the user is to apply per-user policy, and here Netskope leans on SAML, which is why this topic touches the SAML proxy article. In the explicit-proxy path, user identity can be established with a SAML 2.0 IdP, configured under Settings > Security Cloud Platform > Forward Proxy > SAML; the user's browser is set to use port 8081 for this, and the authenticated identity then drives policy. The plain Cloud Explicit Proxy, once a user is identified, relies on cookie surrogates to keep associating subsequent requests with that user. Remote users from unknown locations are required to authenticate to the IdP before browsing. This is the forward-proxy use of SAML (authenticate the user of an outbound session); it is distinct from Netskope's SAML reverse proxy, which inserts into a SaaS application's own SSO flow to control inbound access to sanctioned apps clientlessly, the reverse-proxy side that the SAML proxy article's federation discussion describes.

The pinning problem, and Bypass + Tunnel

Being a forward proxy, Netskope hits the same wall the generic article describes: certificate-pinned applications reject the re-signed certificate and break. Netskope's handling has a useful twist for a cloud proxy. A plain Bypass sends the traffic straight to its destination, skipping Netskope entirely. But pinned applications also have the option to Bypass Netskope Proxy + Tunnel: the traffic is still tunneled to Netskope and egresses through its data plane (so it is still steered and still visible at the connection level), but SSL decryption and policy enforcement are skipped for it. That preserves egress control and some visibility for pinned apps that cannot tolerate interception, and Netskope recommends Bypass + Tunnel over a plain bypass for exactly that reason. It is the cloud-proxy expression of the generic article's rule that a real interception deployment is inspect-by-default plus a maintained set of exceptions for pinned and otherwise un-interceptable traffic.