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?
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:
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.