HTTPS Inspection Best Practices TechTalk: Video, Slides, and Q&A

[PhoneBoy]

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

Content available to CheckMates members:

• Full Video
• Slides

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.

[PhoneBoy]

What is the Performance Impact of HTTPS Inspection?

It is virtually impossible to give you the exact impact without knowing the exact traffic mix. There many parameters here: version in use, traffic mix, policy size, amount of simultaneous sessions, etc. You need to collect your traffic details with the CPSizeme tool and send it to your Check Point office for further analysis.

In general, R80.30 will have much better performance with HTTPS Inspection than previous releases. 

Was a TLS protocol parser used in R77.30? Would that have had the same metrics as R80.10?

R77.30 and R80.10 have similar performance with HTTPS Inspection. In R80.30, the TLS engine was re-done, which yields much better performance.

Is the performance improvement in R80.20 present in older systems doing HTTPS Inspection too, like a 21700?

The performance improvement with HTTPS Inspection in R80.30 is achieved in software. It is relevant for all supported security gateway platforms, Check Point appliances and open servers alike.

Is the protocol parser used in R80.30 the same as R80.40 or has there been further improvements?

Most of the work is done in R80.30 already, with additional improvements coming in R80.40.

Does HTTPS Inspection use SND cores or the Firewall Worker cores for the CPU processing?

Firewall Worker (fwk) instances are doing streaming.

Is TLS 1.3 supported in R80.30?

No, it is planned for a post-R80.40 release.

Will we have to re-issue a new certificate to support SNI on the gateway?

No.

Can you expand a little bit more about the certificate verifications requiring DNS? Are we are just talking that the gateway should have DNS servers configured or something else?

DNS functionality is required on the gateway for general functionality of many features, HTTPS Inspection being one of them. In this specific instance, the gateway should be able to resolve not just the server name, but also CRL distribution points.

Do we need server certs installed on the gateways for HTTPS Inspection to occur?

Your own DMZ servers’ certificates are needed for Inbound HTTPS Inspection. For outbound HTTPS Inspection, a Certificate Authority key must be installed on all clients.

Are Updatable Objects supported in the HTTPS Inspection policy?

Starting from R80.40, yes.

Why do you need a catch-all rule for HTTPS Inspection (i.e. Any Any Bypass)?

Aside from making it clear exactly what is being subject to HTTPS Inspection and what is not, it improves performance substantially to include this rule.

Services "https" and "http proxy" implies port-specific traffic. What about looking across all 65k for HTTPS traffic? Is this issue mitigated by firewall level rule only allowing port 80 or 443?

Only services with HTTPS handler are inspected. For most cases, we are talking about traffic which is going to/from TCP port 443. It is best practice to limit outbound connectivity to known ports in the Access Policy.

One of big challenge with HTTPS inspection is the deployment of the TLS certificate on mobile devices. With R80.x, will there are any solution?

Deploying CA certificates to client devices is required for every vendor's solution. For mobile devices in particular, these could potentially be deployed through MDM. 

Does SNI help URL Filtering blade (without HTTPS Inspection enabled) to identify the custom URL?

In R80.30, you still need to enable HTTPS Inspection to benefit from SNI enforcement. This requirement will be lifted in R80.40.

Can you enable both HTTPS Inspection and HTTPS Categorization?

Yes, starting from R80.20.

Is there a way with threat policy to require TLS 1.2 (ie. block TLS 1.1 and any SSL v3 , etc)?

Yes, this can be done with Application Control and/or IPS.

With R80.30 we have seen cases where the gateway is probing the (remote) server using the gateway's own external IP. What can cause this to happen?

SNI Verification.

Can the drop invalid certificates be built in to a rule to be bypassed for certain networks? Or it is global?

It's a per-domain setting.

In R80.40, can you have multiple HTTPS Inspection layers? Can different layers can be applied to different gateways?

You can define multiple HTTPS Inspection layers but only one can be applied to a given gateway. You can deploy different ones to different gateways, however.

Do the SMB Appliances have any of these enhancements?

Not currently, but it is in the roadmap for SMB appliances running R80.x code (the 1500 Series).

If you can't find the SNI field what will happen then?

Experience shows that more than 95% of TLS Client Hello include SNI. Even without this, the TLS Server Hello includes the certificate. This Subject field of the certificate is checked, which contains the CN (common name) from where the gateway tries to derive the domain name related to the application/site accessed. According to the domain name URLF will determine the related category. According to the URL category a relevant HTTPS inspection policy will match.

[PhoneBoy]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

There is no TLS 1.3 support at the moment.

[Reinhard_Stich]

what abount inbound-SNI?

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

[PhoneBoy]

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...