HTTPS Inspection Best Practices TechTalk: Video, S...

@Peter_Elmer

On 18th December 2019, @Peter_Elmer gave a TechTalk on HTTPS Inspection Best Practices

Content available to CheckMates members:

Selected Q&A asked during the session will be posted as comments to this post.

Excerpt showing off the HTTPS Inspection policy in R80.40 EA below.

(view in My Videos)

PhoneBoy · ‎2019-12-20

More Q&A:

Why do we see sometimes https to sslv3 in logs when inspection is being done?

We can’t comment without log details. Specific issues in production are best worked through the TAC.

Is RAD in (R80.10 JHF 107+) on by default -- once JHF installed? Or does it need to be enabled?

The new RAD implementation discussed is available in R80.30 JHF 107 and later and on by default.

If a company use wildcard certificate is it possible do a block with HTTPS Inspection?

HTTPS policy rules support custom Application/Site objects. The site URL can be described by a regex. In R80.40 FQDN objects are supported that will make this configuration easier.

If the traffic is not going to the standard HTTP/HTTPS port, will it be able to inspect that traffic in the https inspection? Even if that port is not specified in the rule base?

By default, HTTP protocol is inspected on all ports. The HTTPS Inspection policy rules include a service column. Here the services HTTPS TCP/443 and Proxy TCP/8080 are defined by default. Adding other services here (or setting to Any) could potentially impact traffic that is not, in fact, HTTPS.

It is best practice to use the Access Control rule base to block/allow services and applications. HTTP applications using ‘HTTP protected by TLS 1.2’ (HTTPS) as a transport are inspected – once decrypted – by NGTX engine. Security is executed by the NGTX engine according to the Access Control and Threat Prevention rule base.

How about Office 365, does it work fully with HTTPS Inspection?

Office 365 and related applications are supported by Check Point Application Control and URL Filtering. Customers are using HTTPS Inspection on traffic related to these services/applications today.

If you apply the custom TLS v1.2 service to a rule base, would the firewall ignore or still inspect HTTPS? traffic that uses versions other than 1.2?

Access Control rule base executes what is defined and supported. If the default HTTPS service is not used in the Access Control policy and removed from Application Control Advanced > associated services settings, then this service object is no longer used.

We currently have dozens of https inspection bypasses, both by URL and by IP. As we look to move to R80.30, I suspect that many of those bypasses will no longer be needed?

Improvements presented by SNI support should allow for a simplified HTTPS Inspection rule base

Are you planning to have the App signatures updated in the clones of the apps whenever there is a new update in the original App signature?

As far as I know, this is not planned. It is best to raise this requirement with your local Check Point office.

Are update-able objects allowed in the security policy or only in the application blades? and does it require a different license?

Updatable Objects are supported in Access Control as source and destination today in R80.20 and R80.30. In addition to this, R80.40 supports updatable objects in source and destination in the HTTPS inspection policy. No license is required for updatable objects by the time of this writing.

Does the Updatable Object require policy installs to update the object?

The content of Updatable Objects and policy enforcement based on these objects is updated automatically without the need to install policy.

Nolan_Rumble · ‎2020-01-02

Thanks for the video! I had some other questions:

I was wondering when performing the TLS inspection, does the gateway send the full certificate chain (minus the Root CA) to the endpoint, or does it only send the gateway's CA certificate plus the rewritten website certificate (i.e. excluding the intermediate and Root CA's in the chain)?

How does the gateway handle TLS connections where the client is presenting a certificate for Client Authentication? An example is when a government contractor has to use a smart card when accessing a secure government website.

PhoneBoy · ‎2020-01-02

Assuming we're talking about outbound TLS inspection to sites on the Internet, we generate a certificate "on the fly" for the remote site signed by the CA configured on the Security Gateway.
For inbound TLS inspection for sites behind your gateway, we send the same certificate your site does.

TLS Inspection cannot be performed when the client must present a certificate as there is no way for the gateway to authenticate the client certificate.

Nolan_Rumble · ‎2020-01-02

Thanks for the quick response!

I understand the generation of the certificate "on the fly", but what I'm curious about is if the certificate that has just been generated also includes the new full certificate chain from the corporate CA infrastructure versus just sending the generated certificate only. I am asking this because if you perform TLS inspection and you have an Apple device, the Apple device will perform a certificate chain validation, and if the full certificate chain is not present, the Apple device treats the newly generated "on the fly" certificate as untrusted.

For client authentication, is there a way to disable TLS Inspection for certificate exchanges globally where clients might present a certificate for authentication? I was thinking of a use case of disabling TLS inspection if the gateway detects a client certificate being presented for authentication, versus having to wait for the user to point out that something is broken and having to invest time in troubleshooting the problem and ultimately whitelisting the offending site from TLS inspection.

PhoneBoy · ‎2020-01-02

There is only one CA in the chain here: the gateway's CA.
This CA has to be imported into any device subject to TLS Inspection and set to be trusted.
This includes mobile devices.

As for disabling TLS Inspection on attempts at Client Authentication with a certificate, I don't believe we currently do that.
It's possible the enhanced bypass probing mechanism in R80.30 handles this situation, but I don't know for sure.

Nolan_Rumble · ‎2020-01-02

Ah I see. So the gateway is acting as a Root CA issuing web server certificates instead of using a traditional 2-tier/3-tier PKI model where the Root CA is offline and the subordinate CA (gateway) issues the certificates?

Do you know if there's some documentation around Check Point recommending a single-tier PKI approach versus a multi-tier PKI approach for TLS inspection? I struggled to find anything on the Support Center, but it's highly likely I'm not searching with the correct search terms.

Wolfgang · ‎2020-01-03

Nolan,

tha gateway must not act as a root - CA.

As you mentioned you can implement your normal 2-tier/3-tier PKI model where the Root CA is offline.

You have one sub CA for your normal certificate and another sub CA is running on your gateway issuing the certificates on the fly for your clients.

Had a look at:

Best Practices - HTTPS Inspection(configuring certificates)

And this is also described in the documentation Threat Prevention R80.30 admin Guide

Wolfgang

Nolan_Rumble · ‎2020-01-03

Thanks for the response Wolfgang! This article is exactly what I'm looking for. I think where some of my confusion came from was if you import the certificate, and click ok, a popup on the SmartDashboard appears saying "You have not exported the CA certificate yet. Export and install the CA certificate as a valid root CA on computers ..." which would not follow best practices for a multi-tier approach for PKI.

Matthias_Haas · ‎2020-01-03

Hi Nolan,

we are using a sub-ca certificate on the gateway which is signed by a enterprise PKI. In this case you do not need to distibute any certificate to the clients.

Of course, when you set up your PKI you have to distribute the necessary certs (root/ may be sub-CAs).

We did not have to distribute the Checkpoint Sub-CA certificate to the clients which means to me the gateway has to send his Sub CA cert along with the "on the fly" server cert so the client can verify the whole cert-chain.

Matthias

Nolan_Rumble · ‎2020-01-03

Thanks for the response Matthias.

I think my original concern about the certificate chain thing, is that I've seen other vendor's products not send the full chain (as required by the RFC) for this TLS inspection process and only send the gateway's CA certificate and website certificate.

This works fine for a 2-tier PKI deployment (Root CA -> Check Point Gateway CA -> Website certificate), but when there's a 3-tier deployment (Root CA -> Subordinate CA -> Check Point Gateway CA -> website certificate), the gateway only sends the Check Point Gateway CA and website certificate and not the Subordinate CA certificate as part of the chain. By not sending the Subordinate CA, the end device can't evaluate all the way up the chain to the Root CA.

Hope this makes sense?

Thanks for your response! I appreciate it!

Reinhard_Stich · ‎2020-04-28

can check point act as TLS 1.3 client?
so as a "man in the middle" fw1 talks SSL 1.2 to the client - but SSL 1.3 to the server ... is that possible ?

PhoneBoy · ‎2020-04-28

There is no TLS 1.3 support at the moment.

Reinhard_Stich · ‎2020-04-28

what abount inbound-SNI?

so that I can have different HTTPS-servers (and certificates) on the same IP?

PhoneBoy · ‎2020-04-28

Believe so.
We had a pretty extensive thread about this a few months back: https://community.checkpoint.com/t5/IPS-Anti-Virus-Anti-Bot-Anti/Is-there-SNI-support-for-inbound-HT...