- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Hi,
Two questions:
1. Is URL Categorization based on SNI or "Application Name" (CN name ?) when the gateway is deciding on witch category destination falls in to?
2. Does the categorization not being done when destination has a untrusted certificate?
Regards,
Anders Larsson
In earlier release (pre-R80.30) only CN was used, now verified SNI is used when available.
Part of the verification process is checking the cert provided by the remote server matches the SNI requested by the client.
HTTPS Inspection actually requires the certificate be signed by a valid CA, not sure this is required merely for categorization.
When this fails for HTTPS Inspection, there are definitely log messages.
In earlier release (pre-R80.30) only CN was used, now verified SNI is used when available.
Part of the verification process is checking the cert provided by the remote server matches the SNI requested by the client.
HTTPS Inspection actually requires the certificate be signed by a valid CA, not sure this is required merely for categorization.
When this fails for HTTPS Inspection, there are definitely log messages.
Thanks for the reply!
If HTTPS Inspection is not being used only URL-categorization, is there any change of how this is categorized for R81.10?
As @PhoneBoy mentioned, with R80.40 and up, we are using a patented SNI validation. As part of it, we request a site certificate and make sure it is valid and corresponds to the rest of web request data: SNI and URL.
The URL categorization is part of this process, and it is done via HTTPS even if you did not enable HTTPSi on your security GW.
So if the certificate is not trusted there is no categorization?
/Anders
Actually, the change was introduced in R80.30 and backported to R80.20 JHF.
I believe SNI Verification requires HTTPS Inspection to be enabled in R80.20 and R80.30, but it is not required in R80.40 and above.
I am pretty sure what phoneboy said is also done by any other major vendors that do https inspection, but thats the gist of it really.
That is not exactly true, I am afraid. I think you misunderstood what PH conveyed 🙂
How so? 🙂
The main differentiator from the rest of the competitors is SNI validation. Instead of taking it for granted, we actually pull the server certificate and compare its details with the SNI data.
This is, or at least was, unique for Check Point when R80.40 was out, and we filed a patent application for it.
Hope this makes sense.
A kk, I see what you mean, makes sense. Though, Im pretty positive that Fortinet and PAN do it nowdays as well.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 67 | |
| 26 | |
| 13 | |
| 12 | |
| 12 | |
| 9 | |
| 8 | |
| 8 | |
| 8 | |
| 7 |
Tue 21 Apr 2026 @ 05:00 PM (IDT)
AI Security Masters E7: How CPR Broke ChatGPT's Isolation and What It Means for YouTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 21 Apr 2026 @ 05:00 PM (IDT)
AI Security Masters E7: How CPR Broke ChatGPT's Isolation and What It Means for YouTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY