TCP Tunnel Proxy vs SSL Proxy with detect protocol disabled

Products

• Advanced Secure Gateway Software - ASG
• ProxySG Software - SGOS

Issue/Introduction

The Edge SWG (ProxySG) has a TCP Tunnel Proxy and an SSL Proxy service.

The behavior for each service differs with and without protocol detection.

Generally speaking TCP Tunnel Proxy is used to tunnel any TCP-based protocol for which a more specific proxy is not available. The SSL Proxy is used for HTTPS traffic. The question is how the SSL Proxy differs from the TCP Tunnel Proxy when protocol detection is disabled on the SSL Proxy (or enabled on the TCP Tunnel Proxy).

Resolution

There should be no difference in behavior between TCP tunnel with protocol detection enabled and SSL Proxy when the traffic is SSL compliant.

If the first request the client sends is an SSL Client Hello, protocol detection will trigger a handoff to the SSL Proxy service.
The Edge SWG (ProxySG) will behave as if the request came in on an SSL Proxy service  for policy evaluation, handling of access logs, etc.

So, what are the differences? These can best  be summarized as follows:

• With TCP Tunnel Proxy and protocol detection disabled, the Edge SWG (ProxySG) never hands off the traffic to SSL proxy. The Edge SWG will not validate the SSL handshake or the certificates involved, or apply any SSL-related policy to the traffic. SSL traffic will be considered TCP tunnel traffic, and treated as such for evaluating policy and capturing data in the access logs. By default, the log entries will go into the "main" log, not the "ssl" log, and none of the SSL fields will be filled in.
• With TCP Tunnel Proxy and protocol detection enabled, what matters is if the traffic is SSL. If the traffic is SSL, it will be processed just like the SSL Proxy service case below. If not, then there is no handoff to the SSL Proxy and the non-SSL traffic is processed exactly like the case above.
• With SSL proxy, we assume the traffic is SSL and immediately begin parsing it that way. If it is SSL, this will all work fine and we'll evaluate SSL-related policy and do SSL-specific access logging, defaulting to the "ssl" log instead of the "main" log. We'll also validate the SSL handshake and the server certificate by default, though that can be changed in policy. If the traffic is not SSL the proxy will fail to handle the traffic. If the failure is detected relatively early in the flow, and the tunnel-on-error feature is enabled, the request may allow the ProxySG to pass the traffic through. Otherwise the traffic will be rejected, even if there isn't a specific "deny" rule in policy.

Based on the information above, you may want to know the difference between using protocol detection with TCP Tunnel Proxy and tunnel-on-error. The difference is mainly in cases where a client tries to trick a firewall by sending something that initially looks like SSL but then later deviates from that and tries to send a different protocol. The initial packets may be enough to trigger our protocol detection to do the handoff to the SSL proxy, but later parsing in the SSL Proxy will fail. If we still want to allow this pseudo-SSL traffic through, tunnel-on-error has to be enabled. If we only want to allow completely non-SSL traffic through,  TCP Tunnel with protocol detection may be the better choice. It more clearly identifies SSL traffic and lets you write different policy for each type of traffic, where tunnel-on-error doesn't have a way to write policy only on the tunneled traffic. You may need both implementations depending on whether you have clients sending "pseudo-SSL" traffic.

Regarding authentication, there should be no difference in behavior here for real SSL traffic between TCP Tunnel with protocol detection and SSL Proxy. There are some differences for non-SSL traffic or where protocol detection is disabled. In those cases we can only use the TCP Tunnel Proxy, and this requires surrogates or cached credentials to be in place beforehand (in other words the user needs to be have hit the proxy previously with an HTTP/HTTPS session otherwise the authentication will not work). With SSL traffic that gets to the SSL Proxy via transparent mode, we also only have surrogates or cached credentials if we need authentication to make the intercept decision. However, we could always intercept without authentication and later do authentication only on the HTTPS traffic.