> Source: [sk182766](https://support.checkpoint.com/results/sk/sk182766)

# sk182766 - URL Filtering Categorization doesn't block some sites in a blocked category

| Property | Value |
|----------|-------|
| Solution ID | sk182766 |
| Date Created | 2024-10-16 |
| Last Modified | 2024-10-23 |
| Technical Level | Advanced |
| Products | Security Gateway |
| Versions | R82, R81.20 |

## Symptoms

- * After enabling URL filtering and applying blocking rules for certain categories, some sites are not being blocked as expected. The sites are correctly categorized according to [sk69200](https://support.checkpoint.com/results/sk/sk69200) and should fall under the blocked categories.
* After HTTPS inspection is turned on, these sites are blocked.
* Running the following debug:

  `fw ctl debug 0`  
  `
  fw ctl debug -buf 32768`  
  `
  fw ctl debug -m APPI + all`  
  `
  fw ctl debug -m cmi_loader + all`  
  `
  fw ctl debug -m WS + all`  
  `
  fw ctl debug + cmi vm advp conn drop cptls`  
  `
  fw ctl debug -m UP + all`  
  `
  fw ctl set int https_inspection_show_decrypted_data_in_debug 1`  
  `
  fw ctl set int cmi_dump_buffer 1`  
  `
  fw ctl kdebug -t -f > kernel_debug.txt`

  We observed a difference in the Server Name Indication (SNI) when HTTPS Inspection (HTTPSI) is enabled versus when it is disabled.

  From the debug logs:
  * Without HTTPSI (example connection):  
    :64025 -> :443  
    SNI observed:  
    Context 181:  
    176: ............#;
  * With HTTPSI enabled:  
    :63960 -> :443  
    Real SNI observed:  
    Context 181:  

  <br />

## Cause

**Reason for the Difference in SNI:**   
The site uses encrypted SNI (ESNI), a feature now replaced by Encrypted Client Hello (ECH). This encrypts the SNI during the Transport Layer Security (TLS) handshake so that no third party can view it. When HTTPS Inspection (HTTPSI) is disabled, the encrypted SNI (\<some-site.com\>) is observed, whereas, with HTTPSI enabled, we can see the actual SNI (\<site-to-be-blocked.com\>).  
This encryption ensures that only the user, \<some-site.com\>, and the website owner know the specific website being visited. As a result, sites using ECH cannot have their SNI decrypted unless HTTPS Inspection is enabled.  

**Light SSL Explanation:**   
In the Client Hello packet, the SNI is extracted and checked for validity. Light SSL maintains a cache (cptls_host_name_cache) of valid SNI entries. If the SNI is not found in the cache, Light SSL waits for the Server Hello packet to validate the certificate by probing the cloud. Once validated, the SNI is stored in the cache for subsequent connections. After the certificate is confirmed, the SNI is also sent for categorization.  

However, in cases like this, where the site is using ECH, the SNI cannot be decrypted unless we act as a man-in-the-middle (MITM) with HTTPS Inspection. Without this support, connections like the one to \<site-to-be-blocked.com\>, which sends an encrypted Client Hello, cannot be handled properly.

## Solution

This solution requires authentication. Please log in to view the full solution.

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content