There may be privacy and legal regulations on the use of this feature depending on the country in which you are located. Please review your local laws and regulations.
Check Point has not cracked HTTPS or SSL. HTTPS is regarded as secure and is not known to have been cracked.
For HTTPS traffic inspection, Security Gateways must examine the data as clear text. Encrypted data sent by a client to a web server is:
Intercepted by the Security Gateway and decrypted.
Inspected by the blades defined by the policy.
Encrypted again and sent to the designated web server.
The Security Gateway acts as an intermediary between the client computer and the secure web site. The Security Gateway behaves as the client with the server, and as the server with the client using certificates.
A dedicated CA signs certificates, and the Security Gateway presents these certificates to the client. Before the user installs that CA certificate, any site accessed by the browser will produce warnings.
Export the CA certificate from the SmartDashboard (on the HTTPS Inspection window of the Security Gateway, or on the HTTPS Inspection > Gateways pane).
Install the certificate on the user's PC:
Manually put the certificate file in the user's PC. Click the file and follow the wizard instructions to add the certificate to the trusted root certificates repository on client machines.
Use GPO or group policy to distribute the certificate to a large group of users. See the documentation for more details.
When HTTPS Inspection is used, the browser sees server certificates, signed by the gateway, rather than by the original trusted CA. To get the EV indication in the browser, the server certificate must be signed by a specially-designated Certificate Authority. The list of those CA certificates is hard-coded into the browser, and cannot be modified by the user.
Yes. By default, the CRL check is done on the certificate. The check is done without holding the connection, so the first time a user accesses a specific site, it will pass without CRL validation, and the next connection will be validated. By default, if the CRL can't be reached, the certificate is considered to be trusted (this is also the default behavior of the common browsers).
If you wish to enforce CRL fetch, and to mark the certificate as untrusted, if the CRL can not be reached, you can use GuiDBedit Tool to change the value of attribute "drop_if_crl_cannot_be_reached" to "true" (Tables -> "Other" -> "SSL Inspection" table -> "general_confs_obj" Object).
OCSP is supported from R80.10 and from Jumbo Hotfix Accumulator for R77.30 (Take 266).
Connect with SmartDashboard to Security Management Server / Domain Management Server.
Go to Application & URL Filtering tab - on the left, open Advanced - open HTTPS Inspection - click Gateways.
In the CA Certificate section, click the Renew Certificate button - click Import certificate from file... (if no certificate is created yet, click Create first).
The file to import must be a p12 file containing self-signed CA or subordinate CA.
In R8x SmartConsole:
Connect with SmartConsole to Security Management Server / Domain Management Server.
Go to the list of Security Gateways with enabled HTTPS Inspection:
Open HTTPS Inspection configuration in the Legacy SmartDashboard (select any of these options):
On the left Navigation Toolbar, click the MANAGE & SETTINGS - in the upper pane, click on the Blades - in the middle pane, scroll down to the HTTPS Inspection section - click the link Configure in SmartDashboard...:
On the left Navigation Toolbar, click the SECURITY POLICIES - in the left pane, in the Shared Policies section, click the HTTPS Inspection - in the middle pane, click the link Open HTTPS Inspection Policy in SmartDashboard...:
In Legacy SmartDashboard, go to the HTTPS Inspection tab - in the left tree, click the Gateways:
In the lower CA Certificate section, click on the Renew Certificate button - choose the desired option:
Renew Certificate...
Import Certificate from file...
In the lower CA Certificate section, click on the Export... button and save the certificate.
Install this certificate as a valid Root CA on host computers in your organization (refer to the relevant documentation for the operating system on those computers - e.g., for Windows OS, refer to Microsoft documentation).
You can also import a certificate signed by hash algorithm SHA-256.
To filter out sites from HTTPS Inspection, a mapping between the site IP to its correlating domain is needed. The mapping is created based on the certificate DN served by the site. This requires us to perform HTTPS Inspection on any accessed SSL site, at least once. After this mapping is in place, no further inspection will occur (according to the Rule Base). -- This is the underlying reason for the "refresh" success. Note: This behavior is only relevant if there is no proxy between the gateway and the Internet. If there is a proxy, we don't perform full inspection.
No additional information is logged aside from the regular information logged per Blade. The administrator must have special permissions to view this information.
It is possible to use the GUI to remove the victim CA from the list of trusted roots. But this is not recommended, as it would damage connections to other customers of that CA.
Another option is to add the specific certificate serial number to the Black List on the SmartDashboard. This approach has been successfully used by all browser vendors in March 2011, when Comodo was conned into issuing multiple certificates for popular web sites.
Check Point will publish regular updates to the list of CAs, and in the future also to the black-list of known stolen certificates.
HTTPS Inspection is supported in both locally and centrally managed appliances on all platforms deployed with R8x based firmware (1500 series and higher).
On Centrally managed 1100 / 1200R / 1400 HTTPS inspection is supported in R77.20-based firmware.
On Locally managed 700 / 900 / 1400 series HTTPS inspection is supported since R77.20.70.
