- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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.
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.
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.
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.
Most of the work is done in R80.30 already, with additional improvements coming in R80.40.
Firewall Worker (fwk) instances are doing streaming.
No, it is planned for a post-R80.40 release.
No.
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.
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.
Starting from R80.40, yes.
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.
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.
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.
In R80.30, you still need to enable HTTPS Inspection to benefit from SNI enforcement. This requirement will be lifted in R80.40.
Yes, starting from R80.20.
Yes, this can be done with Application Control and/or IPS.
SNI Verification.
It's a per-domain setting.
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.
Not currently, but it is in the roadmap for SMB appliances running R80.x code (the 1500 Series).
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.
More Q&A:
We can’t comment without log details. Specific issues in production are best worked through the TAC.
The new RAD implementation discussed is available in R80.30 JHF 107 and later and on by default.
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.
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.
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.
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.
Improvements presented by SNI support should allow for a simplified HTTPS Inspection rule base
As far as I know, this is not planned. It is best to raise this requirement with your local Check Point office.
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.
The content of Updatable Objects and policy enforcement based on these objects is updated automatically without the need to install policy.
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.
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
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
what abount inbound-SNI?
so that I can have different HTTPS-servers (and certificates) on the same IP?
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY