- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-08-2015 08:18 AM
I'm trying to understand why users can't get a URL Filtering Response Page when they go to SSL-based Web Sites that are not being decrypted by the firewall.
Thanks,
Jeff
04-09-2015 01:21 AM
I replied in #1 : a block/error message requires the original page to be replaced by error page and doing that cannot be done without decrypting since the original page is inside the encrypted connection.
04-08-2015 09:53 AM
it's the purpose of SSL (encrypted) webpages : no one can mess with the content of your website unless he can do a Man in the Middle to decrypt and listen, even change the content. In order to make a nice error message to user any product in the market needs to replace original content of the webpage with that error message and it's only doable if decryption is done.
when we can't decrypt then we drop traffic.
04-08-2015 01:04 PM
URL filtering is done after the session is setup when the http request is made. By this point the session is encrypted including the payload of the url text. So we require decryption in order to read the URL and check the category and apply rules.
04-08-2015 01:18 PM
Hi Steven,
Thank you very much for your answer. I understand why we must SSL Decrypt to be able to see the actual HTTP Get Request. What I don't understand is why the firewall doesn't display a URL Response Page for URL Categories that have an action of either Block, Continue or Override for sites that are SSL but not decrypted by the firewall. What does the firewall do (technically) when it is presented a site that is block, continue or override by the URL Filtering Profile in order for it to present a Response Page?
Thanks,
Jeff
04-08-2015 03:39 PM
I hope below link may help you.
How to Serve a URL Response Page Over an HTTPS Session Without SSL Decryption
04-08-2015 04:20 PM
I already looked at that thread and if you read it closely and implement it, the firewall is actually decrypting the HTTPS sessions. The title is very misleading.
04-08-2015 04:58 PM
If you are using Firefox and see message "(Error code: ssl_error_rx_record_too_long) ", then it means firewall has sent the response page however the browser expected the SSL\TLS handshake.
You can take a packet capture on client machine to see what's happening.
04-09-2015 01:21 AM
I replied in #1 : a block/error message requires the original page to be replaced by error page and doing that cannot be done without decrypting since the original page is inside the encrypted connection.
04-09-2015 05:47 AM
Got it! Thank you very much!
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!