TCP Tunnel Proxy vs SSL Proxy with detect protocol disabled

Products

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

Issue/Introduction

Blue Coat's ProxySG, running SGOS 6.5.x, contains 16 different Proxy types, see Section H: Reference: Proxy Services, Proxy Configurations, and Policy of the SGOS 6.5 Administration Guide for a complete list and details on each of these.

Two such Proxy Types are TCP Tunnel and SSL Proxy.

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

This article will cover how each Proxy behaves under different configuration scenarios and what benefits, disadvantages or side effects each might have.

These are the default settings for TCP Tunnel Proxy


These are the default settings for SSL Proxy


Notice that in both cases the "Detect Protocol" option is disable, so how do each proxies differ?

Resolution

In terms of the differences between the two types of services, the first thing to understand is that there should be no difference in behavior between TCP tunnel with protocol detection enabled and SSL proxy in the case where the traffic is SSL compliant.

As long as the first thing the client sends looks like an SSL Client Hello, protocol detection will trigger a handoff to SSL proxy,
and it will be just as if the service was an SSL Proxy service when it comes to the evaluation of policy, 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, we don't ever hand off the traffic to SSL proxy at all. This means that we won't do any validation of the SSL handshake or the certificates involved, or apply any SSL-related policy to the traffic. SSL traffic will be considered to be TCP tunnel traffic, and treated as such both when evaluating policy and when capturing data in access logs. By default, for instance, 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 whether the traffic is SSL or not. If the traffic is SSL, it will be processed just like the SSL Proxy service case below. If it is not, no handoff to the SSL proxy is done and the non-SSL traffic is process exactly like the case above. Either way, though, we will process the traffic    

 

• 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 do validation of 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, our tunnel-on-error feature may allow the ProxySG to pass the traffic through anyway if that's enabled, but otherwise the traffic will be rejected, even if there isn't a specific "deny" rule in policy for it.

One might ask here what the difference is 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 some other 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, though, TCP Tunnel with protocol detection may be the better choice. It more clearly identifies which traffic is SSL and what is not SSL and actually lets you write different policy for each, where tunnel-on-error doesn't really give you a way to write policy only on the tunneled traffic. In some cases, you may need both, though, depending on whether you have clients sending this "pseudo-SSL" traffic.

Regarding authentication, there really 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, though, or in the case where protocol detection is disabled. In those cases we can only use the TCP Tunnel Proxy, and this requires surrogates or cached credentials be in place before hand (in other words the user needs to be have hit the proxy previously with a HTTP session otherwise the authentication will not work). With SSL traffic that gets to the SSL Proxy in transparent mode, we also only have surrogates or cached credentials if we need authentication to make the intercept decision, but we could choose to always intercept without authentication and then later do authentication only on the HTTPS traffic.