- Products
- Learn
- Local User Groups
- Partners
- More
Introduction to Lakera:
Securing the AI Frontier!
Quantum Spark Management Unleashed!
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!
I just finished reading the Gartner 2019 "Magic Quadrant for Network Firewalls", courtesy of CheckPoint Marketing.
One of the specific "Cautions" they called out for CheckPoint is the lack of TLS 1.3 support, something apparently both Fortinet and Palo Alto already have. BTW: Fortinet and Palo Alto both scored higher and more to the right than CheckPoint in the Leaders quadrant, Palo Alto significantly so.
Does anyone have any knowledge of the timeline for support of TLS 1.3, especially in regards to Threat Prevention / HTTPS inspection? The only info I can find from the Community is a post that's over a year old: https://community.checkpoint.com/t5/General-Management-Topics/Impact-of-upcoming-ESNI-with-TLS-1-3-o..., where Phoneboy said it was to early to say.
Any updates on the topic?
Hi @LCarrau808,
While support for TLS 1.3 in HTTPS Inspection is planned for next year, the Gateway is fully capable of downgrading TLS sessions to TLS 1.2. Because of this, inspection is expected to fail only in cases where websites don't support TLS 1.2 (or below).
TLS 1.2 is supported everywhere and considered secure, so websites and browsers aren't expected to disable it anytime soon. If you see an error screen, it may be because of something else.
Thanks,
Dor
Hi @Dale_Lobb,
Active Streaming (CPAS) - Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.).
General overview:
Active Streaming – https content step by step:
Packets of SSL handshake are passed to the SSL engine to exchange keys. When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets. When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS. The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue. The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server).
More read here:
R80.x - Security Gateway Architecture (Content Inspection)
Hello @PhoneBoy .
Is there a way to configure a Bypass only to websites with TLS 1.3 or a way to prevent the Error Screen on Browsers?
Thanks in advanced.
Lanello
We were "lucky" enough to find a site requiring TLS 1.3 and not lowering to a different cipher if that did not work.
HTTPS Inspection bypass (even knowing the IP of the site) does not resolve the problem.
What can we do in order to allow this site through the firewall in R80.40? I am probably missing something very simple (or I hope so).
This thread is from 2019, but in 2021 here we are with the same problem and upgrading to R81 is not an option at this time.
Thank you.
Bypassing by IP should be sufficient.
This probably require a TAC case.
Hi @LCarrau808,
While support for TLS 1.3 in HTTPS Inspection is planned for next year, the Gateway is fully capable of downgrading TLS sessions to TLS 1.2. Because of this, inspection is expected to fail only in cases where websites don't support TLS 1.2 (or below).
TLS 1.2 is supported everywhere and considered secure, so websites and browsers aren't expected to disable it anytime soon. If you see an error screen, it may be because of something else.
Thanks,
Dor
Hi @Dale_Lobb,
Active Streaming (CPAS) - Check Point Active Streaming active streaming allow the changing of data, we play the role of “man in the middle”. CPAS breaks the connection into two parts using our own stack – this mean, we are responsible for all the stack work (dealing with options, retransmissions, timers etc.).
General overview:
Active Streaming – https content step by step:
Packets of SSL handshake are passed to the SSL engine to exchange keys. When the connection and the SSL handshake is fully established, an hook will be register for this connection to handle the decrypt / encrypt of the packets. When a packet arrive to CPAS, a trap will be sent and the SSL engine will receive the encrypted packet, decode the packet and return it to CPAS. The packet will enter the receive queue and the application will be able to work on it, once he done he will send it to the write queue. The packet will pass to the SSL engine for encryption and pass to the other side (Client, Server).
More read here:
R80.x - Security Gateway Architecture (Content Inspection)
Nice information @HeikoAnkenbrand.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
12 | |
11 | |
9 | |
7 | |
6 | |
6 | |
6 | |
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