URL Blocking not working

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

URL Blocking not working

L1 Bithead

Hello

Can anyone explain why this doesn't work?

I added misoft5.s3.us-east-2.amazonaws.com and misoft5.s3.us-east-2.amazonaws.com/* to my blocked URL list.

If I type in misoft5.s3.us-east-2.amazonaws.com in a browser I get the BLOCKED page. All is well.

But the users are clicking on a bad link,

 https://misoft5.s3.us-east-2.amazonaws.com/login.mcrs0ftonline.com.common.oauth2verifyoutlook.authco...

And that is NOT blocked. WHY NOT???

 

I seem to have this problem every time I block an URL, I feel like I have to add the domain name 5 different ways just so maybe it will be blocked.

I appreciate any help or guidance with this.

I do not have SSL decryption turned on.

 

Thank you

 

5 REPLIES 5

L7 Applicator

Full FQDN blocking on SSL encrypted websites is only possible if the Web Browser being used declares it in the Server Name Indication (SNI) extension which is optional, or if it matches literally with the CN presented in the Server's Certificate. Besides the Web Browser choosing not to expose the FQDN in the SNI, there are two other situations that can prevent URL Filtering matching:
1. The browser in use is Google Chrome, and the connection is established using the QUIC protocol instead of using HTTP(S). The solution is to create a Security Policy at the top of your security policy set blocking application 'quic'.

2. The browser in use is encrypting the Client Hello (ECH) or encrypting the SNI (also known as ESNI), which are options in TLSv1.3. In that case you will not be able to read the SNI and you may need to resort into taking a decision based on the validity of the Root CA signer. You can set a decryption profile without rolling out SSL Decryption, and check with a no-decrypt Decryption Policy to see if the root CA is trusted, and if not, block the connection.

 

The best way to determine what situation you're encountering is to run a packet capture of one of your user's traffic being allowed.

L1 Bithead

Thank you Mivaldi!

A tad more complex than I thought it would be, but thank you very much for your detailed answer.

L0 Member

Sometimes, it works after deleting cache and cooking from the history. You could try. I loved your post so much I became a fan of you, promise that you will continue to share such good and knowledgeable posts even further, we will be waiting for your post thank you.

L0 Member

1.The browser in use is Google Chrome, and the connection is established using the QUIC protocol instead of using HTTP(S). The solution is to create a Security Policy at the top of your security policy set blocking application 'quic'.

2. The browser in use is encrypting the Client Hello (ECH) or encrypting the SNI (also known as ESNI), which are options in TLSv1.3. In that case you will not be able to read the SNI and you may need to resort into taking a decision based on the validity of the Root CA signer. You can set a decryption profile without rolling out SSL Decryption, and check with a no-decrypt Decryption Policy to see if the root CA is trusted, and if not, block the connection.

 

L0 Member

Same issue still no fix to this.

 

 

  • 4596 Views
  • 5 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!