Home Page | Skip to Navigation | Skip to Content | Skip to Search | Skip to Footer
 Support Center > Search Results > SecureKnowledge Details
Support Center
 Print    Email
HTTPS Inspection FAQ

Solution ID: sk65123
Product: HTTPS Inspection
Version: R75.20
OS: SecurePlatform
Platform / Model: All
Date Created: 04-Aug-2011
Last Modified: 12-Mar-2014
Rate this document

Show All

Which software blades support HTTPS inspection?

A: Data Loss Prevention (DLP), Anti Virus, Anti-Bot, Application Control, URL Filtering, Threat Emulation and IPS.

Does HTTPS inspection require a license? Is it a software blade?

A: HTTPS inspection is not a blade and does not require a license. It is included free of charge with other blades.

Are there legal implications to enabling HTTPS inspection in my organization?

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

Has Check Point cracked HTTPS? Could an attacker do this?

A: Check Point has not cracked HTTPS or SSL. HTTPS is regarded 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:

1. Intercepted by the Security Gateway and decrypted.

2. Inspected by the blades set in the policy.

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

Why do I get certificate warnings in the browser after turning on HTTPS inspection?

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

How can I make PCs trust the gateway's CA certificate?

A: To make the PC trust the gateway CA certificate:

1. Export the CA certificate from the SmartDashboard (on the HTTPS Inspection window of the Security Gateway, or on the HTTPS Inspection > Gateways pane).

2. 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 distibute the certificate to a large group of users. See the documentation for more details.

Does HTTPS inspection use the Security Management server's Internal CA to issue certificates?

A: No. HTTPS Inspection uses a dedicated CA.

Is there a performance impact when enabling HTTPS inspection on the gateway?

A: HTTPS inspection requires the Security Gateway to perform extra SSL work:

- SSL handshake with the secure web site and with the client browser.

- Decrypt & re-encrypt all SSL traffic, to be able to inspect it.

This has some performance impact on SSL capacity and latency, but in normal situations the end user should not be aware of it.

Why are Extended Validation (EV) certificates displayed as regular certificates in the browser?

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

How are the CAs in the list of Trusted CAs chosen? Is the list updated?

A: The list of certificate authorities is taken from the Windows system stores. It is updated according to Microsoft updates.

Does HTTPS Inspection check for CRLs? What about OCSP?

A: 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't be reached, you can use GuiDEdit to change the property: "drop_if_crl_cannot_be_reached" to "true". The property is under the Other --> SSL Inspection table, on the general_confs_obj Object.

OCSP is not supported.

Does HTTPS inspection work on protocols other than HTTPs?

A: No, currently it is only possible to inspect HTTPS traffic.

Can I replace the gateway's CA with a different CA?

A: Yes, you can import any CA certificate to be used for HTTPS inspection.

To import a CA certificate:

1. Open SmartDashboard.

2. Go to Application & URL Filtering tab, on the left, open Advanced -> HTTPS Inspection -> Gateways.

3. Below, under CA Certificate, click on Renew Certificate -> Import certificate from file (if no certificate is created yet, need to click on “Create” first).

4. The file to import must be a p12 file containing self-signed CA or subordinate CA.

You can also import a certificate signed by hash algorithm SHA-256.

Is it possible to perform selective inspection – just on specific sites, categories or users?

A: Yes, you can inspect only specific sites or URL Filtering categories (both require a URL Filtering Blade license).

Why do I sometimes get the gateway CA even for sites that are not configured to be decrypted?

A: 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 rulebase). -- 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.

What information from the encrypted traffic is logged?

A: No additional information is logged aside from the regular information logged per Blade. The administrator must have special permissions to view this information.

I read in the news that someone conned the ______ CA to give them certificates for the _______ web site. What should I do?

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

Which SSL/TLS versions of are supported by HTTPS inspection?

A: SSLv3 and TLSv1 (also known as SSLv3.1).

Why isn't SSLv2 supported?

A: SSLv2 is known to be susceptible to several attacks, and as such it is not supported.

Which ciphers are supported by SSL inspection?

A: AES_128_CBC, AES_256_CBC, 3DES_EDE_CBC, RC4_128_MD5, RC4_128_SHA1

This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.
Give us Feedback
Rate this document
Additional comments...(Max 2000 characters allowed)
Characters left: 2000