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