HTTPS Inspection

Outbound HTTPS Inspection

Outbound connections are HTTPS connections that arrive from an internal client to an external server.

Outbound connection flow

1. An HTTPS request (from an internal client to an external server) arrives at the Security Gateway.

2. The Security Gateway intercepts the HTTPS request.

3. The Security Gateway determines whether the HTTPS request matches an existing HTTPS Inspection rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session.:

   • If the HTTPS request does not match a rule, the Security Gateway does not intercept the HTTPS connection.

     In this case, HTTPS Inspection is bypassed.

   • If the HTTPS request matches a rule, the Security Gateway intercepts the HTTPS connection and continues to the next step.

4. The Security Gateway validates the certificate of the external server.

   By default, the Security Gateway uses the Online Certificate Status Protocol (OCSP) to check for certificate revocation.

   If the certificate does not support OCSP, the Security Gateway uses the Certificate Revocation List (CRL) to check for certificate revocation.

5. The Security Gateway creates a new certificate for the connection to the external server.

6. The Security Gateway decrypts HTTPS traffic.

7. The Security Gateway calls the enabled Software Blades to inspect the decrypted HTTPS traffic.

8. If the Security Policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. allows this traffic, the Security Gateway encrypts the HTTP connection.

9. The Security Gateway sends the HTTPS request to the external server.

Inbound HTTPS Inspection

Inbound connections are HTTPS connections that arrive from an external client and connect to a server in the DMZ or the internal network.

Inbound connection flow

1. An HTTPS request (from an external client to an internal server) arrives at the Security Gateway.

   Note - By design, the Security Gateway/Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. is intentionally configured not to perform HTTPS Inspection on traffic directed towards it. To change this behavior, follow sk114574.

2. The Security Gateway intercepts the HTTPS request.

3. The Security Gateway determines whether the HTTPS request matches an existing HTTPS Inspection rule:

   • If the HTTPS request does not match a rule, the Security Gateway does not intercept the HTTPS connection.

     In this case, the HTTPS Inspection is bypassed.

   • If the HTTPS request matches a rule, the Security Gateway intercepts the HTTPS connection and continues to the next step.

4. The Security Gateway uses the certificate for the internal server to create an HTTPS connection with the external client.

5. The Security Gateway creates a new HTTPS connection with the internal server.

6. The Security Gateway decrypts the HTTPS traffic.

7. The Security Gateway calls the enabled Software Blades to inspect the decrypted HTTPS traffic.

8. If the Security Policy allows this traffic, the Security Gateway encrypts the HTTP connection.

9. The Security Gateway sends the HTTPS request to the internal server.

Getting Started with HTTPS Inspection

This section shows an example of how to configure a Security Gateway to intercept outbound and inbound HTTPS traffic.

HTTPS Inspection Policy

The HTTPS Inspection rules define how the Security Gateways intercepts the HTTPS connections.

Starting from R82, the HTTPS Inspection policy is divided into "Inbound Policy" and "Outbound Policy".

The HTTPS Inspection rules can use the URL Filtering Check Point Software Blade on a Security Gateway that allows granular control over which web sites can be accessed by a given group of users, computers or networks. Acronym: URLF. categories to identify traffic for different websites and applications. For example, to protect the privacy of your users, you can use a rule to ignore HTTPS traffic to banks and financial institutions.

By default, a Security Gateway enforces HTTPS Inspection for all enabled supported Software Blades.

To enforce HTTPS Inspection for a specific Software Blade, you must:

1. Enable the required Software Blade Specific security solution (module): (1) On a Security Gateway, each Software Blade inspects specific characteristics of the traffic (2) On a Management Server, each Software Blade enables different management capabilities. in the Security Gateway object.

2. Create an applicable rule in the HTTPS Inspection policy and in the Blade column, select the required Software Blade.

You can create different HTTPS Inspection layers in different policy packages. When you create a new policy package, you can use the pre-defined HTTPS Inspection layer, or customize the HTTPS Inspection layer to fit your security needs.

You can share an HTTPS Inspection layer across multiple policy packages.

Columns in HTTPS Inspection Security Policy

These are the columns in the HTTPS Inspection Security Policy rules:

(To show or hide columns, right-click any column header.)

Column	Description
No.	Rule number in the HTTPS Inspection Rule Base All rules configured in a given Security Policy. Synonym: Rulebase..
Name	Name that the system administrator gives this rule.
Source	Network object that defines where the traffic starts.
Destination	Network object that defines the destination of the traffic.
Services	The services (protocols) that are intercepted or bypassed. By default, the services https on port 443 and HTTP_and_HTTPS proxy on port 8080 are intercepted. You can add or delete services in this column.
Site Category	Categories for applications or web sites that are intercepted or bypassed.
Action	The action taken by the Security Gateway when it matches HTTPS traffic to a rule. Inspect - The Security Gateway intercepts the HTTPS connection. Bypass - The Security Gateway does not intercept the HTTPS connection. Important - For more information about the connection flow and this action, see: Outbound HTTPS Inspection Inbound HTTPS Inspection
Track	Tracking and logging action that is done when traffic matches the rule.
Blade	By default, contains the value "All" to inspect the decrypted HTTPS traffic by all the enabled supported Software Blades. You can select specific Software Blades to inspect the decrypted HTTPS traffic.
Install On	Security Gateways that will enforce this HTTPS Inspection Policy. By default, this column contains the object Policy HTTPS Targets. This object automatically applies to all Security Gateways that have HTTPS Inspection enabled. In this column, you can only select Security Gateways that have HTTPS Inspection enabled.
Certificate	This column exists only in the "Inbound Policy". In this column, you select the certificate that the internal server uses for the rule.
Comment	An optional field to add a description for the rule.

Sample Outbound HTTPS Inspection Rule Base

This table shows a sample HTTPS Inspection Outbound Rule Base for a typical policy.

No	Name	Source	Destination	Services	Site Category	Action	Track	Install On
1	Financial sites	*Any	Internet	https HTTP_HTTPS_proxy	Financial Services	Bypass	Log	HTTPS Policy Targets
2	Outbound traffic	*Any	Internet	https HTTP_HTTPS_proxy	Any	Inspect	Log	HTTPS Policy Targets

1. Financial sites - This is a bypass rule that does not intercept HTTPS connections to websites that are defined in the "Financial Services" category.

2. Outbound traffic - This rule intercepts HTTPS connections to the Internet. This rule uses the Outbound CA certificate.

Sample Inbound HTTPS Inspection rule

This table shows a sample HTTPS Inspection Inbound rule for a typical policy.

No	Name	Source	Destination	Services	Action	Certificate
1	Inbound traffic	*Any	WebCalendarServer	https	Inspect	WebCalendarServer CA

Inbound traffic - This rule intercepts HTTPS connections to the network object WebCalendarServer. This rule uses the WebCalendarServer certificate.

HTTPS Inspection Policy Enforcement

HTTPS Inspection Rule Base enforcement consists of two steps:

1. Matching the connection against the Rule Base.

2. Calculating the action to be performed.

The action is calculated according to the matched rule, the Software Blades defined on the matched rule and the rule exceptions. In certain scenarios, the action in the matched rule is Inspect, but as a result of Step 2, the action is changed to Bypass. In such case, the HTTPS Inspection log is sent with data from the matched rule, but the action in the logged action is Bypass.

Working with Inbound CA Certificates

By design, the Security Gateway / Security Cluster is intentionally configured not to perform HTTPS Inspection on traffic directed towards it. To change this behavior, follow sk114574.

To add a server certificate for inbound HTTPS Inspection

Step	Instructions
1	In SmartConsole, go to Security Policies view > HTTPS Inspection > Inbound Policy > from the top toolbar, click Inbound Certificates.
2	Click Import. The Import Inbound Certificate window opens.
3	Enter a Certificate name and a Comment (optional).
4	Browse to the certificate file.
5	Enter the Password. Enter the same password that was used to protect the private key of the certificate on the server.
6	Click OK.
7	Click Close.

The Successful Import window opens the first time you import a server certificate. It shows you where to add the object in the HTTPS Inspection policy.

Click Don't show this again if you do not want to see the window each time you import a server certificate and Close.

Configuring HTTPS Inspection on the Security Gateway

You must configure HTTPS Inspection on each Security Gateway separately.

To configure HTTPS Inspection on a Security Gateway:

Working with Outbound CA Certificates

The outbound CA certificates are used by the Security Gateways managed on the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server.. The first time you enable HTTPS Inspection on one of the Security Gateways, you must create an outbound CA certificate for HTTPS Inspection or import a CA certificate already deployed in your organization. Starting from R82, you can create or import additional outbound certificates.

Creating an Outbound CA Certificate

The outbound CA certificate is saved with a CER file extension and uses a password to encrypt the private key of the file. The Security Gateways use this password to sign certificates for the HTTPS Inspection. You must keep this password secure because it is also used by other Security Management Servers that import the CA certificate to open the file.

After you create an outbound CA certificate, you must export it so it can be distributed to internal clients. If you do not deploy the generated outbound CA certificate on internal clients, users receive TLS error messages in their browsers when connecting to HTTPS sites. You can configure a troubleshooting option that logs such connections.

After you create the outbound CA certificate, use it in rules that intercept outbound HTTPS traffic in the HTTPS Inspection policy.

Importing an Outbound CA Certificate

You can import a CA certificate that is already deployed in your organization or import a CA certificate created on one Security Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. to another Security Management Server.

For each Security Management Server that has Security Gateways with HTTPS Inspection enabled, you must:

1. Import the CA certificate.

2. Enter the password the Security Management Server uses to open the CA certificate file and sign the certificates for users. Use this password only when you import the certificate to a new Security Management Server.

Exporting and Deploying the Generated CA Certificate

To prevent users from getting warnings about the generated CA certificates that HTTPS Inspection uses, install the generated CA certificate used by HTTPS Inspection as a trusted CA. You can distribute the CA with different distribution mechanisms such as Windows GPO. This adds the generated CA to the trusted root certificates repository on client computers.

When users run standard updates, the generated CA is in the CA list and they do not receive certificate warnings in their browsers.

To distribute a certificate with a GPO

Step	Instructions
1	Export the certificate from the Security Gateway: To export an outbound certificate, use one of these two options: Option 1 In SmartConsole, go to the Security Policies view > HTTPS Inspection > Outbound Policy. In the top tool bar, click Outbound Certificates. The Manage Outbound Certificates window opens. Select the required certificate, and click the button. Select the required folder in which to save the certificate, and click Save. Option 2 In SmartConsole > the Gateways & Servers view > double-click the required Security Gateway object. The Security Gateway object editor opens. From the left menu, go to HTTPS Inspection. In Step 2, click Export Certificate. Select the required folder in which to save the certificate, and click Save
2	Use the Group Policy Management Console to add the certificate to the Trusted Root Certification Authorities certificate store. See Deploying Certificates using Group Policy.
3	Push the GPO Policy to the client computers in the organization. Note - Make sure that the CA certificate is pushed to the client computer organizational unit.
4	Test the CA certificate distribution by browsing to an HTTPS site from one of the client computers. Also, make sure the CA certificate shows the name you entered for the CA certificate that you created in the Issued by field.

Deploying Certificates using Group Policy

You can use this procedure to deploy a certificate to multiple client computers with Active Directory Domain Services and a Group Policy Object (GPO). A GPO can contain multiple configuration options, and is applied to all computers in the scope of the GPO.

To deploy a certificate using Group Policy

Step	Instructions
1	On the Microsoft Windows Server, open the Group Policy Management Console.
2	Find an existing GPO or create a new GPO to contain the certificate settings. Make sure the GPO is associated with the domain, site, or organization unit whose users you want affected by the policy.
3	Right-click the GPO and select Edit. The Group Policy Management Editor opens and shows the contents of the policy object.
4	Open Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers.
5	Click Action > Import.
6	Do the instructions in the Certificate Import Wizard to find and import the certificate you exported from SmartConsole.
7	In the navigation pane, click Trusted Root Certification Authorities and repeat steps 5-6 to install a copy of the certificate to that store.

Working with Trusted CAs for Outbound HTTPS Inspection

When a client initiates a TLS connection to a server, the Security Gateway intercepts the TLS connection. The Security Gateway intercepts the traffic and creates a new TLS connection from the Security Gateway to the designated server.

When the Security Gateway establishes a TLS connection to the designated server, it must validate the server certificate.

HTTPS Inspection comes with a preconfigured list of trusted CAs. This list is updated by Check Point when necessary and is downloaded automatically from the Check Point Download Center to the Management Server. After you get the Trusted CA update on the Security Management Server, you must install the policy on the Security Gateways. You can select to disable the automatic update option and manually update the Trusted CA list. See sk64521.

If the Security Gateway receives a non-trusted server certificate, by default the user gets a self-signed certificate and not the generated certificate. A page notifies the user that there is a problem with the server security certificate, but lets the user continue to the server.

You can change the default setting to block untrusted server certificates. Go to Security Policies > HTTPS Inspection > HTTPS Inspection Tools > Advanced Settings > Server Validations > select Untrusted server certificates.

To manage the list of Trusted Certificates, in SmartConsole, go to the Security Policies view > HTTPS Inspection > in the HTTPS Inspection Tools section, click Trusted Certificates.

You can do these actions, in the Trusted Certificates window:

• In the Trusted CAs Package tab:

  • You can check if the trusted CAs package is up-to-date. You can see details about the downloaded package version, the last update timestamp, and the last check for these statuses. You can update the certificates in one of two ways:

    • Automatic update:

      Select Update Trusted CA package automatically. The Trusted CAs package is updated automatically once a day at 2:00 AM.

    • Manual update:

      Select Updated Trusted CAs Package manually, and click Update Now or Import Trusted CAs Package, to manually update the package.

  • In the Certificates section, you can view all certificates included in the package, export certificates, enable or disable certificates.

    To enable or disable certificates:

    1. Select the applicable certificates using the checkboxes.

       Note - You can select all certificates by clicking the top checkbox.

    2. From the top-menu, click Actions, and select Enable or Disable

• In the Custom Trusted Certificates tab, you can import, export or delete a certificate.

HTTPS Inspection Global Settings

You can configure HTTPS Inspection global settings for all Security Gateways in Security Policies > HTTPS Inspection > HTTPS Inspection Tools > Advanced Settings.

Fail Mode

To change the global settings for the fail mode

1. Go to the Security Policies view> HTTPS Inspection > Inbound Policy or Outbound Policy > in the HTTPS Inspection Tools section, click Advanced Settings.

2. Go to Fail Mode, and select the applicable settings:

   1. In Server Side Fail Mode, select one of these options:

      • Bypass all requests (Fail-Open)

      • Block all requests (Fail-Close)

   2. In Client Side Fail Mode, select one of these options:

      • Bypass all requests (Fail-Open)

      • Block all requests (Fail-Close)

      Notes: In the Fail-Open mode, the Security Gateway blocks the first connection, but does not intercept subsequent connections with the same source and destination hostname, it bypasses them. In the Security Gateway versions R81.20 and lower, in case of a client-side error, the connection is always blocked (Fail-Close). You cannot change the behavior in these versions.

Categorization Mode

Configure a mode for categorizing HTTPS sites:

• Background - All requests are allowed until categorization is complete. When a request cannot be categorized with a cached response, an uncategorized response is received. Access to the site is allowed. In the background, the Check Point Online Web Service continues the categorization procedure. The response is then cached locally for future requests. This option reduces latency in the categorization procedure.

• Hold - This is the default setting. When a request cannot be categorized with the cached responses, it remains blocked until the Check Point Online Web Service completes categorization.

Server Validations

When a Security Gateway receives an untrusted certificate from a website server, the settings in this section define when to drop the connection.

• Untrusted server certificate:

  • When selected traffic from a site with an untrusted server certificate is immediately dropped. The user gets an error page that states that the browser cannot display the webpage.

  • When cleared, a self-signed certificate shows on the client machine when there is traffic from an untrusted server. The user is notified that there is a problem with the website's security certificate, but the user can continue to the website (default).

• Revoked server certificate (validate CRL):

  • When selected, the Security Gateway validates the site certificate of each server. The Security Gateway validates the certificate using the Online Certificate Status Protocol (OCSP) standard. OCSP is faster and uses much less memory than Certificate Revocation List (CRL) Validation, which is used for certificate validation in releases lower than R80.10.

  • When cleared, the Security Gateway does not check for revocations of server site certificates.

  If OCSP is not supported for a server certificate, the Security Gateway uses CRL validation. If the CRL cannot be reached, the certificate is considered trusted. This is the default configuration. An HTTPS Inspection log is issued that indicates that the CRL could not be reached.

  You can change this behavior in Database Tool (GuiDBEdit Tool):

  Procedure

  Important - This change applies to all Security Gateways with enabled HTTPS Inspection

  1. Close all SmartConsole windows.

  2. Connect with the Database Tool (GuiDBEdit Tool) to the Management Server.

  3. In the top left panel, click Other > ssl_inspection.

  4. In the top right panel, click general_confs_obj and change.

  5. In the bottom panel, right-click the attribute "drop_if_crl_cannot_be_reached" > click Edit.

  6. Change the value from "false" to "true" > click OK.

  7. From the top, click the File menu and click Save All.

  8. Close the Database Tool (GuiDBEdit Tool).

  9. Connect with SmartConsole to the Management Server.

  10. Install the Access Control policy.

  To validate the CRL, the Security Gateway must have access to the Internet. For example, if a proxy server is used in the organizational environment, you must configure the Security Gateway to use this proxy server.

  To configure the proxy server for the Security Gateway:

  Optionally, you can use the default proxy server configured in SmartConsole Global Properties.

  1. In SmartConsole, go to the Gateways & Servers view, and double-click the Security Gateway that requires proxy configuration.

  2. Go to Network Management > Proxy.

  3. Select Use custom proxy settings for this network object and Use proxy server, and enter the proxy IP address.

  4. Click OK.

  5. Install the Access Control policy.

  Important - Make sure that there is a rule in the Rule Base that allows outgoing HTTP from the Security Gateway

• Expired Server Certificate

  • When selected, the Security Gateway drops the connection if the server certificate expired.

  • When cleared, the Security Gateway creates a certificate with the expired date. The user can continue to the website (default).

• Track validation errors

  Select whether to log the server validation (you can see the logs in the Logs & Events view > Logs in SmartConsole), or trigger other notifications.

Certificate Blocking

You can create a list of certificates that are blocked. Traffic from servers using these certificates is dropped. If a certificate in the list is also in the Trusted CAs list, the block certificate list overrides the Trusted CAs list.

• New - Lets you add a certificate. Enter the certificate serial number (in hexadecimal format HH:HH) and a comment that describes the certificate.

• Edit - Lets you change the details of the blocked certificate list.

• Delete - Lets you delete a certificate from the blocked certificate list.

• Search - Lets you search for a certificate in the blocked certificate list.

• Track dropped traffic - Select whether to log the server validation (you can see the logs in the Logs & Events view > Logs in SmartConsole), or trigger other notifications.

Bypass Allow Lists

• Well-known update services - Some well-known update services must be bypassed to function correctly. For the list of updated services, see sk98655.

• Certificate-pinned Applications - Some mobile and desktop applications trust only specific server certificates. Such applications may terminate the connection due to a trust issue when presented with a certificate signed by HTTPS Inspection’s outbound CA certificate. When a connection from a client which is classified as a certificate-pinned application is detected, the selected action is taken.

Available actions:

Session Logs

Starting in R82, the Security Gateway can send session logs, which provide a visual overview of the TLS traffic passing through it.

To allow the Security Gateway to send these logs:

1. Select Send session logs.

2. In the HTTPS Inspection Rule Base, set the Track column of the applicable rules to Log.

HTTPS Inspection session logs group individual connections into session logs based on several common characteristics:

• Source IP

• Destination IP

• SNI (Server Name Indication)

• HTTPS Inspection Action: Whether the traffic is bypassed or intercepted.

• Bypass Reason: Applicable only if the traffic is bypassed.

• Time Window: Connections that occur within the same 3-hour period.

By aggregating connections with these characteristics, session logs are used to create statistics views, including Bypass and Inspect decisions. For more details, see HTTPS Inspection Statistics View.

Other

Intermediate CA

Use the "Certificate Authority Information Access" extension to retrieve certificates that are missing from the certificate action.

Automatically retrieve intermediate CA certificates:

• When selected, intermediate CA certificates issued by trusted root CA certificates that are not part of the certificate chain are automatically retrieved using the information on the certificate (default).

• When cleared, a web server certificate signed by an intermediate CA and not sent as part of the certificate chain, is considered untrusted.

Bypass Under Load Logging

To configure the log type for Bypass Under Load:

1. Go to the Security Policies view > HTTPS Inspection > Inbound Policy or Outbound Policy

2. In the HTTPS Inspection Tools section, click Advanced Settings.

3. Click Other.

4. In the Bypass Under Load Logging section, in the Track field, select the applicable option.

5. Click OK.

6. Install the Access Control policy.

SNI support for Site Categorization

Starting from R80.30, a new functionality allows the categorization of HTTPS sites before the HTTPS Inspection begins, and prevents connectivity failure if the inspection does not succeed.

SNI is an extension to the TLS protocol, which indicates the hostname at the start of the TLS handshaking process.

The categorization is performed by examining the SNI field in the client hello message at the beginning of the TLS handshaking process. To make sure that you reached the right site, the SNI is verified against the Subject Alternative Name of the host, which appears in the certificate.

After the identity of the host is known and verified, the site is categorized, and it is determined whether the connection should be intercepted or not.

SNI support is enabled by default.

HTTPS Inspection on Non-Standard Ports

Applications that use HTTP normally send the HTTP traffic to the TCP port 80. Some applications send HTTP traffic on other ports also. You can configure some Software Blades to only inspect HTTP traffic on port 80, or to also inspect HTTP traffic on non-standard ports.

The security policies inspect all HTTP traffic, even if it is sent using non-standard ports. This option is enabled by default. You can configure this option in the Manage & Settings view > Blades > Threat Prevention > Advanced Settings > General > HTTPS Inspection. If you make this change, you must install the Access Control policy.

Inspection of TLS v1.3 Traffic

Starting from R81, the Check Point Security Gateway can intercept traffic that relies on Transport Layer Security (TLS) v1.3 (see RFC 8446).

From R81.10, this feature is enabled by default for Security Gateways (and Cluster Members) that use the User Space Firewall (USFW)).

For the list of supported platforms, see sk167052.

Limitations

• The Security Gateways supports HTTP/3 inspection only when it runs in the User Space Firewall (USFW) mode, which is the default in versions R82 and higher.

  The Security Gateway downgrades HTTP/3 traffic to an earlier HTTP version when it operates in the kernel mode firewall.

  For information about the User Space Firewall (USFW) mode, see the Release Notes for your version and sk167052.

• The Security Gateway drops HTTP/3 traffic when the Threat Prevention "Deep Inspection" mode is enabled.

• Chromium-based web browsers allow HTTP/3 traffic only if the HTTPS Inspection certificate is signed by a trusted CA from the Chromium trust list.

  Chromium-based web browsers do not allow adding certificates for HTTP/3 traffic to the browser's trusted store. See sk111754.

• Inspection of QUIC traffic over a proxy is not supported.

• All other protocols, except HTTP/3, will be downgraded to an earlier HTTP version.