Hi,
according to Symantec KB, a "TCP Tunnel" service with Detect protocol enabled should be equivalent to "SSL Proxy" service when encountering SSL traffic:
https://support.symantec.com/us/en/article.tech245661.html
Yet the behavior is confusing in the following scenario:
- SSL intercept on exception is enabled (the default)
- TCP Tunnel on port 443 with Detect protocol enabled
- Category "Technology/Internet" is set to Deny in web access policy (this is just an example)
- web site https://veracompadria.com is categorized as "Technology/Internet" and its IP adress has the same category, too.
When accessing the web site, the proxy manages to perform intercept on exception and return HTTP response 403 (denied) to the client, which is expected.
However, the exception template returned is not the HTML data for HTTP traffic but rather the exception text used for all protocols: "$(exception.id): $(exception.details)". This is a very basic message omitting any HTML code we usually return to the user. So, the proxy performs full interception and is able to return HTTP(S) response to the client, but it incorrectly uses the exception template for all protocols (without the html).
Furthermore, if the site above were not categorized as "Technology/Internet" for its *IP address* (but was categorized on url level), the proxy would have returned the full HTTP exception with HTML i.e. "$(exception.format)"
This is completely unexpected behavior. What should be done to get expected HTML exception for https traffic in such cases? I know that reverting to SSL Proxy instead of TCP tunnel would "solve" the problem, but that's not possible for this customer due to other apps not tolerating "SSL proxy" service only.
any insights appreciated.
Above is the expected exception with HTML, below is the unexpected exception.
Image may be NSFW.
Clik here to view.
