- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Yes, you can find more details about this in sk101226.
In $FWDIR/log on the management, the two main Network/Threat Prevention logs have an extension of .log (Security Logs) and .adtlog (Audit Logs). The other files are necessary to work with these log files in SmartView/SmartConsole. The files should have a date/time stamp in their name.
Some features do require being in USFW mode (HTTPS Inspection for TLS 1.3/2.0 come to mind). Performance should be similar in either mode.
We recently did a Deep Dive on the enhancements coming in R82: https://community.checkpoint.com/t5/Management/Deep-Dive-on-the-latest-R82-TLS-Inspection-Enhancemen...
Server Name Indication (SNI) has historically been "in the clear" (thus why we verify the SNI before using it for a Security Policy decision). With Encrypted SNI, the only way to see the site would either be the CN of the certificate or full HTTPS Inspection.
Unless you have a specific reason to change it, use the default setting. More details about USFW in sk167052.
This should be allowed through implied rules.
No, you need to add a bypass rule to HTTPSi policy and apply it
fw monitor can create a capture file in snoop format with the -o filename option. This file can be read in Wireshark (see sk39510).
asg diag should be used on Maestro.
Yes
It is not a single process, please look for sk115657 for the details.
Refer to sk35496.
You need to start with the Security Logs. Based on what's shown there, then you can drill down.
There are some limitations with it, it all depends on the use case.
Look into sk33422.
You can look into NAT tables per VS
In some instances, yes.
HyperFlow (present in R81.20 and above) only works for connections in Medium Path.
R82 should have some additional improvements.
It might be that one of the advanced blades interferes. You need to look into logs, before anything else.
fast_accel moves specified traffic into the Accelerated Path, which does not support IPS and other Threat Prevention blades.
VPN Encryption/Decryption is handled in SecureXL.
Please see sk43733.
See sk173024
Not always, but it depends on the rulebase construction. For more details, see: Unified Policy Column-Based Rule Matching
Depends on the features in use. Additional performance improvements are coming in R82.
This is usually related to the policy.
Identity Awareness.
Bypass rules should always be placed at the top of the rulebase. You can have as many as desired.
HTTPS Inspection will support QUIC in R82.
Great session - Thank you very much!
Thank you very Much, Great Session Mr. Dameon
ECH use in TLS 1.3 prevents the possibility of performing HTTPS inspection altogether.
If we're terminating the TLS connection on the gateway itself (which happens with HTTPS Inspection), we should be able to see it.
Having said that, I'll confirm with R&D,
Hi @PhoneBoy, did you get a reply from R&D regarding ECH usage in TLS 1.3?
I think if the TLS connection is terminated on the gateway, everything should be fine. But HTTPS Bypass rules won't work as they rely on the SNI which can't be seen with ECH when the connection is not decrypted, right?
SNI information is actually in the clear, which is why we actually verify the requested SNI as part of the process.
If the SNI is encrypted (i.e. because of ECH), then we obviously won't be able to see it (e.g. as part of bypass rules).
(if i am allowed to add our experience:)
regarding: "https inspection, we heve the issue sometimes that an https exception rule will not work unless its at the top of the rule base.":
we had similar problems. (we are on r81.10)
conclusion: put your bypass-rules with ip- and domain-destinations on top,
put your bypass-rules with appl- and url(customapplication)-destinations near the bottom of your https-policy.
because: if a bypass-rule with appl/url-destination could match, cp has to inspect the connection anyway at first.
if it sees the connection should have been bypassed, it will send a tcp-reset, so the client will reinit/retry the connection. some client-programs have problems with that.
Appreciate you offering your experience, and agree this is best practice.
Great job Dameon! Looking forward to presenting Part Deux of the "Be Your Own TAC" series at CPX 2025 Las Vegas!
Looking forward to it, too. 🙂
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
13 | |
12 | |
11 | |
8 | |
8 | |
7 | |
5 | |
5 | |
5 | |
5 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY