HTTP responses fail or time out when SSL Interception is enabled on Edge SWG

Products

• ISG Proxy
• ProxySG Software - SGOS

Issue/Introduction

You may experience issues where GET or POST requests through the Edge SWG (ProxySG) fail, time out, or experience significant delays when SSL Interception is enabled. This typically occurs even though policy traces indicate the proxy is receiving data from the server.

Symptoms include:

• GET requests for continuous data streams (such as Server-Sent Events) time out after approximately 30 seconds.
• Policy traces show bytes received from the server but 0 bytes sent to the client.
• HTTP 307 Temporary Redirects or other responses are held by the proxy for several minutes until the server-side connection terminates.
• The issue does not occur when the proxy is bypassed, as browsers may handle malformed or continuous streams more gracefully than the proxy's inspection engine.

Environment

• Edge SWG (ProxySG)
• SSL Interception enabled
• Traffic involving Server-Sent Events (SSE) or malformed chunked encoding

Cause

The issue is caused by the proxy attempting to buffer the HTTP response to perform content analysis, such as "apparent data type" identification or ICAP scanning.

Two specific triggers for this behavior are:

1. Continuous Streams: In scenarios like Server-Sent Events, the "end" of the file never arrives. The proxy continues to wait for more data to complete its analysis before forwarding it, causing the client to time out.
2. Malformed Chunked Encoding: If a server sends a response using Transfer-Encoding: chunked but fails to send the required terminator, the proxy assumes more data is coming. It holds the payload (including redirect headers) until the connection is closed.

Resolution

To resolve the timeout or delay, you must configure the Edge SWG to immediately forward response headers and data to the client rather than holding or buffering it for inspection. The issue occurs because the proxy waits for enough response body data to perform policy evaluation, such as "apparent data type" checks. This waiting period can indefinitely delay continuous streams or responses where the server fails to properly terminate chunked encoding.

Apply the http.response.response_data.prevent_inspection_delay(yes) policy for the affected traffic. This policy instructs the proxy to proceed with sending the response headers to the client without waiting for response body data for policy inspection. It will skip response-based policies if the data is not immediately available and will always pass response data back to the client as soon as it arrives.

Important Note: Applying this policy means that response apparent data type checks may not work reliably for the affected responses, since the proxy will pass data back to the client as it arrives rather than waiting to accumulate enough data for policy evaluation.

1. Identify the specific destination domains or URLs experiencing the timeout.
2. Apply the following Content Policy Language (CPL) in a local policy file or CPL layer:

<Proxy>
url.domain=example.com http.response.response_data.prevent_inspection_delay(yes)

Note: Replace example.com with the specific domain identified in step 1.

Additional Information

Enabling prevent_inspection_delay(yes) may impact the reliability of policy checks that rely on "apparent data type" identification, as the proxy will no longer wait to accumulate enough data for a definitive identification before forwarding.