cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
6578
Views
5
Helpful
4
Replies

Firesight URL filtering - not showing block page for https websites

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

1 Accepted Solution

Accepted Solutions

Sunil Kumar
Cisco Employee
Cisco Employee

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 !!

View solution in original post

4 Replies 4

smoores
Level 1
Level 1

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.

Sunil Kumar
Cisco Employee
Cisco Employee

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 !!

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

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

Review Cisco Networking products for a $25 gift card