Why do bad DNS names and failed connections to servers not get SSL intercepted?


Article ID: 167511


Updated On:


ProxySG Software - SGOS


When using the "Intercept On Exception" feature, many error messages and policy messages will be delivered to clients attempting to go to SSL sites - even if you do not normally intercept SSL traffic. Bad DNS names or servers that do not respond to the ProxySG's attempt to establish a connection do not get intercepted.

This is due to a technical limitation in the way SSL interception works. If https://www.example.com was denied and a client attempted to connect to that site, the proxy would do SSL interception by doing the following:
1. Acknowledge the client's SSL "Client Hello" message
2. Open a connection to https://www.example.com to retrieve the SSL certificate from that site
3. Use the Common Name and Validity Period to create a new, on-the-fly certificate to present to the client
4. Respond to the client with an SSL "Server Hello" message, and then the newly created certificate
5. Serve the "access denied" exception page to the client

The above steps (specifically step 2) cannot be done when the client is going to a hostname that does not exist or a server that is down. Since the ProxySG cannot determine the Common Name or the Validity Period from the server, it does not have enough information to generate a certificate on the fly to serve to the client. Therefore, the ProxySG simply closes the connection with the client.