02-09-2016 11:01 PM - edited 03-12-2019 05:53 AM
Hello All,
I have configured URL filtering to block certain pages. I have configured ssl decryption as well. But I noticed that when an https website is blocked firesight is not showing the block page. When http website is blocked the block page is showing properly. Is this a limitation in the firesight?. The firesight version is 6.0.
Thanks in advance
Shabeeb
Solved! Go to Solution.
02-13-2016 02:52 AM
SSL web filtering occurs with server certificate's common name. When end user open any SSL based website. End System does the TCP handshake with the server then SSL handshake starts.
The sensor monitors the SSL handshake and when the server sends the Server certificate. Sensor matches the common name of the certificate with access rule (URL-based rules). If it matches then sensor blocks the connection during the SSL handshake. Hence, the connection has been blocked before reaching to application protocol (HTTP GET request) so the system does not send any response page.
The sensor does the certificate resign (SSL decryption) when it receive the server certificate but at the same time/ packet (server certificate) common name matches to access rule (URL blocking) to block the connection. Hence, blocking of connection has occurred so SSL decryption does not happen. In this way, the system can save some resources (CPU/ Memory).
Regards,
Sunil Kumar
Rate if it helps !!
02-12-2016 11:08 AM
Not suppose to be but it absolutely is. Upon much investigation (working with Cisco TAC) it appears to be due to the order of operations. Once a URL is blocked, further processing does not occur including applying the SSL policy. Actually decoding the SSL is necessary to inject the block page into the conversation we we never get to the SSL policy if the URL is blocked.
02-13-2016 02:52 AM
SSL web filtering occurs with server certificate's common name. When end user open any SSL based website. End System does the TCP handshake with the server then SSL handshake starts.
The sensor monitors the SSL handshake and when the server sends the Server certificate. Sensor matches the common name of the certificate with access rule (URL-based rules). If it matches then sensor blocks the connection during the SSL handshake. Hence, the connection has been blocked before reaching to application protocol (HTTP GET request) so the system does not send any response page.
The sensor does the certificate resign (SSL decryption) when it receive the server certificate but at the same time/ packet (server certificate) common name matches to access rule (URL blocking) to block the connection. Hence, blocking of connection has occurred so SSL decryption does not happen. In this way, the system can save some resources (CPU/ Memory).
Regards,
Sunil Kumar
Rate if it helps !!
11-15-2017 04:46 AM
Hello,
will this behaviour be adressed in a future release? More and more websites tend towards ssl/https, so the block page feature as it exists today is losing its usability.
Kr,
Piet
02-13-2016 02:08 PM
Hi Sunil,
Thanks a lot for the clarification. I opened TAC and got the same response from them. Can you have a look at my another post which is for blocking nested files inside zip?
https://supportforums.cisco.com/discussion/12886076/firesight-not-blocking-exe-file-inside-zip-archive
Thanks in advance
Shabeeb
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide