06-08-2021 08:40 AM
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,
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
06-08-2021 04:41 PM - edited 06-11-2021 04:59 PM
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.
06-10-2021 05:27 AM
Thank you Mivaldi!
A tad more complex than I thought it would be, but thank you very much for your detailed answer.
12-09-2021 10:52 PM - last edited on 12-27-2021 09:10 AM by jdelio
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.
12-14-2021 01:56 AM - last edited on 12-27-2021 09:11 AM by jdelio
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.
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!
