What real protection do we get from Threat Prevention if HTTPS inspection is disabled?

[Chinmaya_Naik]

Hello everyone,

Our situation:
We have Threat Prevention blades enabled on a Check Point firewall—Anti‑Virus, IPS, Anti‑Bot, etc. But HTTPS (SSL/TLS) inspection is turned OFF.

1. What we know:

• Without SSL inspection, Firewall cannot decrypt encrypted HTTPS traffic, so it cannot inspect the content inside that traffic. It only sees the IP addresses and ports.
• Since about 85–95 % of web traffic is HTTPS, most traffic remains uninspected.
• Without decryption, our Threat Prevention blades cannot detect malware, phishing links, bots, or data leaks hidden in HTTPS .
• In effect, we are blind to threats inside encrypted traffic; our heavy security investment may be going to waste  .

2. So what benefits remain of Threat Prevention without SSL inspection?

• We only get protection for cleartext traffic (HTTP, SMTP, FTP, etc.).
• We can still block obvious network-level attacks (port scans, header anomalies), but application-layer threats in HTTPS are untouched  .

4. Our conclusion so far:

• With HTTPS inspection OFF, threat prevention on encrypted traffic is effectively disabled.
• Without decryption, there is no content-level scanning, meaning zero protection for a large chunk of traffic.

My questions to the community:

1. Is our understanding correct? In short, without HTTPS inspection, Threat Prevention features don’t work on encrypted traffic?
2. Are there any real use cases where disabling HTTPS inspection still gives valuable security from Check Point Threat Prevention blades?
3. Which security features do still work on HTTPS traffic if inspection is off (e.g., header-based IPS rules, reputation checks, etc.)?
4. What are best practices for deploying HTTPS inspection in environments concerned about privacy, performance, or compliance?

Regards,

@Chinmaya_Naik 

[_Val_ · Accepted solution]

I would re-phrase p.4 in a slightly less aggressive manner:

With HTTPSi off, most of the Threat Prevention features will be much less effective. 

You can say, all signature-based features will not work on encrypted connections, but Threat Prevention has some other tools.  SNI verification will still work, for example, making sure that at least categorization of TLS sites will work, even if you cannot see inside the traffic.

Here are my answers to your four questions.

1. In general sense, and considering over 90% of web traffic is now TLS, HTTPSi is highly recommended for the Internet-facing security gateways.
2. HTTPSi may not be that critical for internal segmentation. 
3. Threat Prevention is a collection of thousands of different protections. Pattern-matching will not work on the encrypted traffic, but other protections will still be effective, including SNI-based categorization, reputation, DNS traps, and others.
4. R82 provides you with an option of automated learning mode and gradual deployment of TLS Inspection policies, which is what you are looking for. For any previous version, you need to proceed with extreme caution and make sure you understand your traffic before you implement HTTPSi. HTTPSi Best Practices is a very vast topic; it is impossible to provide you with a comprehensive answer in a few sentences. Owning the system, knowing what to expect and what to protect is a key.

[Chinmaya_Naik]

@_Val_ 

Thank you very much.

I do agree that signature-based protections are crucial, but I’d like to better understand the actual value of the other features that still operate when HTTPS Inspection is disabled.

Signature-based protection:
• These protections (IPS, AV, Anti-Bot) rely on pattern matching inside traffic payloads—for example, looking for known malware files or exploit code.
• However, since encrypted traffic is unreadable without HTTPSi, signatures cannot analyze or block threats hidden within HTTPS streams.

What still works without SSL Inspection

1. SNI-based categorization
• Zero-Phishing can block malicious HTTPS sites by reading the SNI field (domain name) in the TLS handshake, even without decryption.
2. DNS traps and reputation checks
• Firewall can catch known-malicious domains at DNS lookup, or block based on domain/IP reputation—even if the traffic is encrypted.
3. Certificate info analysis
• The firewall can inspect certificate metadata (issuer, expiry, trust chain) to detect suspicious or self-signed certs.

But… how effective are non-signature protections?
• These remaining features only see metadata, not the actual content. They cannot detect payload-based threats such as file-based malware, phishing links inside HTTPS, or C&C traffic.
• Considering more than 85–90% of web traffic is HTTPS, the firewall is effectively blind to most threats without SSL inspection   .
• Signature-based detections are still the strongest defense. The other features are supplemental—they add value, but cannot replace payload inspections.

So here are my questions:

1. Is this understanding correct—that only metadata-based protections work when HTTPSi is off, and signature-based analytics are disabled in HTTPS flows?
2. Can these metadata-based features practically reduce risk, or are they only useful for some phishing/malicious-domain scenarios?
3. In your experience, are there cases where it may be sufficient to rely on these instead of full HTTPS Inspection—especially in environments with privacy, compliance, or performance constraints?

Thank you again for your guidance.

Regards

@Chinmaya_Naik 

[_Val_]

1. Asked and answered already

2. Risks are reduced to some extent, but not significantly.

3. I never give any general recommendations. Actual security design is always unique, and strongly depends on what you are training to protect, how, and acceptable risk margins.

[PhoneBoy]

As you note, there are some environments where you cannot use HTTPS Inspection.
This includes regulatory, privacy, and technical reasons (e.g. sites/apps that require Client Certificates for Authentication or use Certificate Pinning).
Even if you can't see the payload, at some point that payload has to be delivered somewhere, does it not?
That usually involves a DNS lookup and/or outbound connection somewhere, where DNS/IP/SNI protections will still apply.
Which means even without HTTPS Inspection, Threat Prevention can still reduce the associated risks.

[Bob_Zimmerman]

Also worth noting HTTPS Inspection is for HTTP. Plenty of traffic isn't that. Off the top of my head, SSH/SCP/SFTP, various SQLs, VoIP traffic, BGP, DNS, and most email aren't HTTP-like and mostly don't use TLS. VoIP audio traffic sometimes uses DTLS, but HTTPS Inspection doesn't deal with DTLS, does it?

So protections for non-HTTP traffic are mostly or fully functional without HTTPS Inspection.

[the_rock]

Hey brother,

Long time no talk, how goes it? You pretty much nailed all the points. Put it this way...probably more than 90% of world's web traffic nowdays is indeed https, so it only makes sense to have ssl inspection on. Now, if that, for whatever reasons, cant be done, I would still have threat prevention on, as that can only help. yes, its true that they wont work on encrypted traffic, but having it on is definitely recommended.

@_Val_ provided very good answers.

Andy

[PhoneBoy · Accepted solution]

We now have an official SK for this topic along with some real-world examples: https://support.checkpoint.com/results/sk/sk184185 

[the_rock]

Nice!