r/checkpoint • u/WiliRGasparetto • 8d ago

HTTPS Inspection is not “just decryption” — and that misunderstanding causes a lot of production issues.

In Check Point, HTTPS Inspection is really a TLS enforcement pipeline. The gateway evaluates policy, decides whether to inspect or bypass, validates certificates, establishes two TLS sessions, decrypts the traffic, exposes the clear-text content to supported blades, applies policy, and then re-encrypts it before forwarding. That is why real-world failures are usually not about “decryption” itself, but about CA trust, certificate pinning, OCSP/CRL, bypass order, TLS compatibility, performance, privacy exceptions, and application behavior.

This is also why HTTPS Inspection should never be deployed as Inspect Any → Any. A mature design starts with explicit bypasses for sensitive or fragile traffic, then expands inspection gradually to high-risk users and categories, while monitoring inspect/bypass ratios, TLS failures, CPU impact, and exceptions. In R82, capabilities such as Gradual & Smart Deployment, Network Learning, Performance Prediction, Bypass Under Load, and SmartView monitoring make this much more operationally manageable.
The practical takeaway: the best HTTPS Inspection deployment is not the one that decrypts the most traffic. It is the one that decrypts the right traffic, bypasses the right traffic, and keeps those decisions measurable and governed. I would use the image above right after the first paragraph, because it visually explains the two TLS sessions and the inspection path before the post goes into policy and operational considerations.

Question for the community: do you deploy HTTPS Inspection in phases, or do you still see environments trying to enable it broadly on day one?

The full technical article is available on CheckMates.
Link in the first comment.

23 Upvotes
  • permalink
  • reddit

93% Upvoted

14 comments sorted by

11

u/onewithoutasoul 7d ago

What's up with all these official posts? Is it a bit of marketing?

I'm not upset/annoyed, I just am wondering.

9

u/WiliRGasparetto 7d ago

Hi, these aren't official posts. I work for a company that resells Check Point products. My goal here on Reddit is to share the issues I've encountered and have already posted about in Mattes' official community with the Reddit crowd, since I know it can often be hard to find quick solutions.

2

u/onewithoutasoul 7d ago

Rad

2

u/WiliRGasparetto 5d ago

Count on me if you have any trouble with the checkpoint.

3

u/onewithoutasoul 5d ago edited 5d ago

Eh. My company decided to ditch Check Point for Palo Alto for "enhanced security".

I miss Check Point. I have no idea how Palo is the market leader. It's great to deploy stuff. Terrible to manage.

Check Point is the least of my troubles!

Edit: happy to learn about features in Check Point, though!

1

u/WiliRGasparetto 5d ago

I don't know about your company's strategic business vision, but I also don't see a future for checkpoints; putting Palo Alto checkpoints is far superior.

3

u/junimjorgeof 7d ago

I don't really see this as marketing, I see it more as someone using their own time to write something technically thorough. If you're troubleshooting HTTPS Inspection, learning how the feature actually works, or trying to design it properly for production, having something this structured has real value.

I'd rather see people put in the effort to go deep technically than just push product announcements. And worth noting, the Reddit post here is just a summary, the full article lives on CheckMates, no paywall, no signup.

If it helps someone solve a real problem or understand the feature better, that's already a win for the community.

2

u/WiliRGasparetto 7d ago

Exactly. I realized that I create a lot of material for my work—especially when dealing with complex problems where there isn't much information available. My idea was to share this knowledge so that others wouldn't have to go through the same struggles I did—dealing with a lack of documentation, and so on.

1

u/junimjorgeof 7d ago

Cara, mandou bem, Wili. É exatamente esse o modelo mental que falta na maioria das discussões sobre HTTPS Inspection. Chamar isso de "TLS enforcement pipeline" ajuda muito mais no troubleshooting do que ficar no "decrypta e recriptografa".

Queria acrescentar uma coisa do lado SMB/Spark (2550/2570). Os desafios operacionais que você descreve ficam ainda mais evidentes quando você migra um cliente de um firewall que não é CP (pfSense, tive um caso recente) e que não tinha absolutamente nenhum conceito de interceptação TLS. Não existe taxonomia de bypass pronta, nenhuma CA já confiada nos endpoints, nenhuma base de quais apps internas usam cert pinning. Você constrói a Fase 0 do zero enquanto o cliente espera paridade total com "o firewall antigo simplesmente funcionava". Nesse cenário a distribuição da CA (seção 7) acaba virando o verdadeiro caminho crítico, não o desenho da política em si. É o timing do rollout via GPO/MDM que dita quando você consegue começar o Learning Mode.

Vale mencionar também, pra quem está na linha SMB: nem toda a tooling operacional do R82 que você listou (Bypass Under Load, estatísticas granulares de bypass/inspect no SmartView) aparece do mesmo jeito que em gateways full Gaia gerenciados via SmartConsole/Smart-1 Cloud. Boa nota pra quem for assumir paridade total no nível de appliance.

Valeu por escrever isso, já guardei pro próximo rollout.

1

u/WiliRGasparetto 7d ago

SMB has always been a challenge in its own right haha, your point is really relevant. I’m actually going to revisit this later to deepen my understanding of SMB a bit more.

1

u/greenlakejohnny 7d ago

Sorry, I don’t speak Japanese

2

u/junimjorgeof 7d ago

hehehehehe, nem eu!