R82 Security Management Administration Guide

HTTPS Inspection

HTTPS Internet traffic uses the TLS (Transport Layer Security) protocol and is encrypted to give data privacy and integrity. However, HTTPS traffic has a possible security risk and can hide illegal user activity and malicious traffic. The enabled Software Blades on the Security Gateway cannot inspect HTTPS traffic because it is encrypted. HTTPS InspectionFeature on a Check Point Firewall that inspects traffic encrypted by the Secure Sockets Layer (SSL) protocol for malware or suspicious patterns. Synonym: SSL Inspection. Acronyms: HTTPSI, HTTPSi. lets the Security Gateway intercept TLS connections and decrypt their traffic for inspection by the enabled Software Blades.

There are two modes of HTTPS Inspection:

• Outbound HTTPS Inspection - To protect against malicious traffic that is sent from an internal client to an external site or server.

• Inbound HTTPS Inspection - To protect internal servers from malicious requests that arrive from the Internet or an external network.

The Security Gateway uses certificates and becomes an intermediary between the client computer and the secure web site. All data is kept private in HTTPS Inspection logs. Only administrators with HTTPS Inspection permissions can see all the fields in such logs.

For information on what's new in HTTPS Inspection starting from R80.20, see sk163594.

Limitations

• CRL validation is not supported in pure IPv6 environments (when IPv4 addresses are not configured on the Security Gateway's interfaces).

• In the HTTPS Inspection policy, when selecting the same action that already appears in the Action column, the Security Management ServerDedicated 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. records it as a change within the SmartConsoleCheck Point GUI application used to manage a Check Point environment - configure Security Policies, configure devices, monitor products and events, install updates, and so on. session.

• 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.
  • Protocols that rely on QUIC, except HTTP/3, will be downgraded to an earlier HTTP version.

Intercepting HTTPS Connections

Outbound HTTPS Inspection

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

Outbound connection flow](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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 ruleSet 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 PolicyCollection 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](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

1. An HTTPS request (from an external client to an internal 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:

   • 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 FilteringSoftware Blade on a Check Point Firewall 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.

These are the Software Blades that support HTTPS Inspection:

• Access Control:

  • Application ControlSoftware Blade on a Check Point Firewall that allows granular control over specific web-enabled applications by using deep packet inspection. Acronym: APPI.

• URL Filtering

• Content AwarenessSoftware Blade on a Check Point Firewall that provides data visibility and enforcement. Acronym: CTNT.

• Data Loss PreventionSoftware Blade on a Check Point Firewall that detects and prevents the unauthorized transmission of confidential information outside the organization. Acronym: DLP.

• Threat Prevention:

  • IPSSoftware Blade on a Check Point Firewall that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System).

• Anti-VirusSoftware Blade on a Check Point Firewall that uses real-time virus signatures and anomaly-based protections from ThreatCloud to detect and block malware at the Check Point Firewall before users are affected. Acronym: AV.

• Anti-BotSoftware Blade on a Check Point Firewall that blocks botnet behavior and communication to Command and Control (C&C) centers. Acronyms: AB, ABOT.

• Threat EmulationSoftware Blade on a Check Point Firewall that monitors the behavior of files in a sandbox to determine whether or not they are malicious. Acronym: TE.

• Threat ExtractionSoftware Blade on a Check Point Firewall that removes malicious content from files. Acronym: TEX.

• Zero PhishingSoftware Blade on a Check Point Firewall (R81.20 and higher) that provides real-time phishing prevention based on URLs. Acronym: ZPH.

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

1. Enable the required Software BladeSpecific security solution (module): (1) On a Check Point Firewall, 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 InspectionSecurity Policy](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

These are the columns in the HTTPS InspectionSecurity Policy rules:

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

• Inspect - The Security Gateway intercepts the HTTPS connection.

• Bypass - The Security Gateway does not intercept the HTTPS connection.

Configuring HTTPS Inspection Policy

Establish distinct HTTPS Inspection rules for outbound and inbound traffic within the corresponding outbound and inbound policies.

The inbound rules use a different certificate for each internal server.

You can also create bypass rules for traffic that is sensitive and should not be intercepted. Make sure that the bypass rules are at the top of the Outbound Policy.

Sample Outbound HTTPS InspectionRule Base](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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

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](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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

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

HTTPS Inspection Policy Enforcement

HTTPS InspectionRule 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.

Assigning a Server Certificate for Inbound HTTPS Inspection

When a client from outside the organization initiates an HTTPS connection to an internal web server (for example, a server located in the organization's DMZ behind the Security Gateway, the Security Gateway can intercept the traffic.

To perform HTTPS Inspection in this scenario, the Security Gateway must impersonate the internal web server.

This requires the Security Gateway to present the TLS certificate of the internal web server and have access to the server's certificate private key.

Therefore, the administrator must export the certificate and the private key from the internal web server in the *.p12 format (which includes both) and then import this P12 file to SmartConsole.

After importing the server's certificate, the administrator can add the corresponding certificate object to the HTTPS Inspection Inbound Policy.

To add a server certificate for inbound HTTPS Inspection](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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:

In case of a client or a server connection error, you can select one of these modes:

• Fail Open - The Security Gateway does not perform HTTPS Inspection on connections that failed on the server side or client side (HTTPS Inspection is bypassed).

• Fail Close - The Security Gateway blocks connections that failed as a result of internal system error or server connection error (server side error) or as a result of client connectivity issues.

You can handle server and client errors based on the global settings, or override the global settings for the specific Security Gateway. To configure Fail-mode configuration globally for all Security Gateways, see Fail Mode.

To configure fail mode for a specific Security Gateway:

1. In Additional Settings, click Edit.

The HTTPS Inspection Settings window opens.

2. Configure Server Side Fail Mode - In case of an internal system error or a server connection error, select one of these options:
   • Use the global setting - The default global setting is Fail Open.

• Override global settings - Select Fail-Open or Fail-Close.

3. Client-Side Fail Mode- In case of a client connectivity issue is detected, select one of these two options:

• Use the global setting - The default global setting is Fail Open.

• Override global settings - Select Fail-Open or Fail-Close.

This feature is disabled by default.

HTTPS Inspection Deployment View

This view presents the statuses and recommendations for Security Gateways with HTTPS Inspection enabled in Learning Mode.

It also shows the inspection status of each Security Gateway, as follows:

• Full inspection - Displayed when Full Inspection is configured on the Security Gateway. The Security Gateway intercepts all HTTPS connections based on the configured HTTPS Inspection policy.

• Learning mode - Displayed when Learning mode is configured on the Security Gateway. Here you can see the effect of the learning mode deployment and a recommendation regarding the deployment of HTTPS Inspection.

• Categorized HTTPS Inspection only - Displayed when HTTPS Inspection is disabled on the Security Gateway and Categorized HTTPS websites is globally configured (Manage and Settings view > Blades > Application Control & URL Filtering > Advanced Settings > URL Filtering).

• Disabled - HTTPS Inspection is not enabled on the Security Gateway and the Categorized HTTPS websites option is disabled.

Working with Outbound CA Certificates

The outbound CA certificates are used by the Security Gateways managed on the Security Management ServerCheck Point Single-Domain Security Management Server or a Multi-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.

To create an outbound CA certificate](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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

To import an outbound CA certificate](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

Deploying Certificates using Group Policy

You can use this procedure to deploy a certificate to multiple client computers with Active DirectoryDomain 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](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

Exporting a Certificate from one Security Management Server to Another

If you use more than one Security Management Server in your organization, you must first export the CA certificate with the "export_https_cert" CLI command from the Security Management Server on which it was created before you can import it to other Security Management Servers.

Command syntax](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

To export the CA certificate](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

On the Security Management Server, run this command:

Example:

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 InspectionTools 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:

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

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](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

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.

• 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

Check Point dynamically updates lists of well-known update services and certificate-pinned applications that can be bypassed for improved connectivity.

• 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 InspectionRule 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.

HTTPS Inspection Statistics View

Starting in R82, you can view HTTPS Inspection statistics in the Logs & Events view and in SmartView. The HTTPS Inspection statistics view provides a visual overview of HTTPS traffic that passes through the Security Gateway, including bypass and inspect statistics. The Statistics view is updated every time the Security Gateway sends a session log. (see Session Logs).

Configuration

1. Enable the required Software Blades on the Management Server or Log Server](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

2. Connect with SmartConsole to the Management Server.

3. On the left navigation panel, go to the Gateways & Servers view.

4. Double-click the object of the Management Server or Log ServerDedicated Check Point server that runs Check Point software to store and process logs., to which the Security Gateway sends its logs.

5. In the left panel, click General Properties.

6. In the Management tab, select these Software Blades:

   • Logging & Status

• SmartEvent Server

• SmartEvent Correlation Unit

7. Click OK and publish your changes.

8. In the top left corner, click Menu > Install database.

9. Select all objects and click Install.

10. Monitor the task progress in the bottom left corner.

11. Enable HTTPS Inspection session logs on the Security Gateway](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

12. In SmartConsole, go to the Manage & Settings view > Blades > HTTPS Inspection > Advanced Settings.

The HTTPS Inspection - Global Settings window opens.

2. In the left navigation tree, go to Session Logs.

3. Select Session Logs and click OK.

Viewing HTTPS Inspection Statistics

You can view the HTTPS Inspection statistics in these two locations:

In SmartConsole](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

1. On the left navigation panel, click Logs & Events.

2. At the top, click [+] to open a new tab.

3. In the left section, click Views.

4. In the top search field, enter: HTTPS.

5. Double-click the view called HTTPS Inspection Statistics.

In SmartView](https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Content/Topics-SECMG/HTTPS-Inspection.htm?cshid=ID004#)

1. With a web browser, connect to the SmartView portal on the Management Server or Log Server, to which the Security Gateway sends its logs.

For example:

https://192.168.22.33/smartview/

2. At the top, click [+] to open a new tab.

3. In the left section, click Views.

4. In the top search field, enter: HTTPS

5. Double-click the view HTTPS Inspection Statistics

To see log details:

1. In the HTTPS Inspection Statistics view, double-click the applicable chart or graph to see all the related session logs.

2. Double-click the applicable session log to see all the related connection logs (appear in the bottom panel).

3. Double-click the applicable connection log to see the complete log details.

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

Inspection of HTTP/3 protocol (RFC 9114)

Starting from R82, Check PointSecurity Gateways can inspect the decrypted inbound and outbound HTTP/3 traffic based on the configuration of the enabled Software Blades.

HTTP/3 is a new version of the HTTP protocol designed to improve speed, reliability, and security, by using the QUIC transport protocol, which operates over UDP instead of TCP. The HTTP/3 protocol ( RFC 9114) optimizes transport of HTTP semantics over QUIC.

HTTP/3 retains all core features of HTTP/2, while enhancing efficiency through reduced latency and improved performance.

HTTP/3 over TLS enables HTTP/3 connections over a secure TLS connection.

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.

Using HTTPS/3 the in a Rule Base

For transparent QUIC inspection, the QUIC service was added default HTTPS services group. You can use it in the Access Control policy in the Services & Applications column, and in the HTTPS Inspection policy, in the Services column.

For example:

Monitoring the HTTP/3 inspection

You can view the HTTP/3 inspection statistics on the Security Gateway in CPView:

1. Connect to the command line on the Security Gateway, and run:

cpview

2. At the top, click Advanced > HTTP-Parser > QUIC.

Example output:

|-----------------------------------------------------------------------------------------------------------------------------------------------------------|

| CPVIEW.Advanced.HTTP-Parser.QUIC                                                                                                       13Jul2024 16:48:27 |

| Overview SysInfo Network CPU I/O Software-blades Hardware-Health Management Advanced                                                                      |

| Logging CPU-Profiler Memory Network SDWAN SecureXL ClusterXL CoreXL PrioQ Streaming NAT MUX Routed RAD Conn-Tracker UP HTTP-Parser SSH-Parser CPAQ       >>

| General HTTP3-Information QUIC                                                                                                                            |

| Connections overview                                                                                                                                      |

|                                                                                                                                                           |

| Processed Connections:                                          0                                                                                         |

| HTTPS Inspection - Inspect:                                     0                                                                                         |

| Website Categorization:                                         0                                                                                         |

| HTTPS Inspection - Bypass on first packet:                      0                                                                                         |

| HTTPS Inspection - Bypass on category/app:                      0                                                                                         |

| Downgraded:                                                     0                                                                                         |

| Closed with error:                                              0                                                                                         |

| --------------------------------------------------------------------------------------------------------------------------------------------------------- |

| Downgrade reasons                                                                                                                                         |

|                                                                                                                                                           |

| QUIC inspection disabled               0                                                                                                                  |

| Strict Hold is active                  0                                                                                                                  |

| Exception                              0                                                                                                                  |

| QUIC Errors                                                                                                                                               |

|                                                                                                                                                           |

| Error type                                                      # of errors             # in the last 10 min window                                       |

| Unknown error                                                   0                       0                                                                 |

| Transport internal error                                        0                       0                                                                 |

| Connection refused                                              0                       0                                                                 |

| Flow control violation on stream                                0                       0                                                                 |

| Frame exceeding stream limits                                   0                       0                                                                 |

| Received frame mismatch with stream state                       0                       0                                                                 |

| New final size mismatch with previous final size                0                       0                                                                 |

| Could not decode frame                                          0                       0                                                                 |

| Bad transport parameters                                        0                       0                                                                 |

| Received connection ID going over the limit                     0                       0                                                                 |

| Protocol violation                                              0                       0                                                                 |

| Invalid token                                                   0                       0                                                                 |

| Connection timeout due to lack of progress                      0                       0                                                                 |

| Crypto buffer exceeded crypto level in stream                   0                       0                                                                 |

| Key update error                                                0                       0                                                                 |

| AEAD limit reached                                              0                       0                                                                 |

| No viable path                                                  0                       0                                                                 |

| Cannot create control stream: peer-imposed limit                0                       0                                                                 |

| HTTP internal error                                             0                       0                                                                 |

| Cannot create stream                                            0                       0                                                                 |

| Critical stream closed                                          0                       0                                                                 |

| Unexpected frame received on stream                             0                       0                                                                 |

| Malfored frame: could not parse frame                           0                       0                                                                 |

| Excessive load                                                  0                       0                                                                 |

| Invalid stream ID                                               0                       0                                                                 |

| Unexpected HTTP/2 setting                                       0                       0                                                                 |

| First control frame is not SETTINGS                             0                       0                                                                 |

| Got stream while going away                                     0                       0                                                                 |

| Refuse push stream                                              0                       0                                                                 |

| Request is incomplete                                           0                       0                                                                 |

| Parsing error: frame contains invalid headers                   0                       0                                                                 |

| Content error                                                   0                       0                                                                 |

| Version fallback                                                0                       0                                                                 |

| Stream QPACK decompression error                                0                       0                                                                 |

| Error interpreting QPACK encoder stream                         0                       0                                                                 |

| Error interpreting QPACK decoder stream                         0                       0                                                                 |

| Invalid certificate                                             0                       0                                                                 |

22 July 2026

© 2024 - 2026Check Point Software Technologies Ltd.