sk108202 - Best Practices - HTTPS Inspection

Best Practices - HTTPS Inspection

Solution

This article outlines some recommendations and best practices for easy HTTPS Inspection deployment and usage to help avoid common configuration issues.

Table of Contents:

  1. HTTPS Inspection - Inbound vs. Outbound

  2. Gradual Deployment

  3. Initial configuration

  1. Configuring inbound certificates

  2. Configuring outbound certificates

  3. Creating the HTTPS Inspection Rule Base

  4. Internet connection

  5. Monitor TLS connections

  1. Perfect Forward Secrecy Cipher Suites

  2. Certificate-pinned Applications

  3. Update Services

  4. Traffic over QUIC or HTTP/3

  5. Categorized HTTPS vs. HTTPS Inspection

  6. HTTPS Inspection support for Post-Quantum Cryptography (PQC)

  1. Notes

  2. WSTLSD daemon (TLS handshake)

  3. Firewall debug

  4. HTTPS Inspection rulebase matching

(Part 1) Introduction

HTTPS Internet traffic uses the TLS (Transport Layer Security) or SSL (Secure Sockets Layer) 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.

With HTTPS Inspection, the Security Gateway can inspect the traffic that is encrypted by HTTPS.

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

HTTPS ratio of internet traffic is constantly growing.

However, malicious attacks, dangerous web activity and data loss can hide away from the inspection of the Security Gateway under the TLS layer.

Therefore, we recommend to enable HTTPS Inspection to improve security.

By enabling HTTPS Inspection, the Security Gateway will inspect the encrypted parts of the HTTPS traffic.

The HTTPS Inspection Rule Base is a set of rules used to define which HTTPS traffic will be inspected by the Security Gateway.

The inspection will be performed by all the Software Blades that support HTTPS Inspection:

(Part 1 - 1) Introduction: HTTPS Inspection - Inbound vs. Outbound

Note: There are bypass mechanisms which were not elaborated in the flowchart to keep it simple.

(Part 1 - 2) Introduction: Gradual Deployment

When first enabling HTTPS Inspection, we recommend to use a gradual approach. Consider one of the following methods:

  1. Starting from R82, the Learning Mode feature offers a way to partially deploy HTTPS Inspection and estimate its effect on connectivity and performance issues. With Learning mode, the Security Gateway inspects a small percentage of the traffic to identify connectivity issues and estimate the expected resource consumption for the configured HTTPS Inspection policy. In HTTPS Inspection Deployment View you can see the effect of the learning mode and the statuses of all Security Gateways. For more details, refer to HTTPS Inspection Learning Mode recommendation.

    Note - We recommend to configure Learning Mode with a rule that inspects all networks to ensure that sufficient data is collected for generating accurate recommendations.

  2. In all versions, you can perform a manual gradual deployment - Begin with a few Security Gateways and networks, and expand from there to cover all Security Gateways and networks. Do this by configuring the HTTPS Inspection rulebase to inspect a single subnet or few subnets and enabling HTTPS Inspection on a single Security Gateway at first. then expand to cover all Security Gateways and networks.

(Part 1 - 3) Introduction: Initial configuration

For more information, see the Threat Prevention Administration Guide for the relevant version > chapter "HTTPS Inspection".

(Part 2) Best Practices

(Part 2 - 1) Best Practices: Configuring inbound certificates

When importing an internal server's certificate for inbound traffic inspection, it is necessary to include all the intermediate CAs of the chain in the *.p12 file.

Inclusion of only the server certificate may cause some browsers to warn about untrusted sites, since some browsers are unable to fetch and validate the complete certificate chain.

Management Server versions R82 and higher:

Management Server versions R81.20 and lower:

Note:

Making sure all intermediate certificates in the chain are signed with SHA-256 to avoid browser warnings

For both inbound and outbound HTTPS Inspection, validate that all intermediate certificates in the chain are signed with SHA-256 (or higher) algorithm.

Otherwise, browsers may warn (either by icon next to the URL, or in other ways) that the connection is not secure enough.

This limitation applies only to intermediate certificates in the chain, and not to root CAs.

(Part 2 - 2) Best Practices: Configuring outbound certificates

The outbound CA certificate is used to sign the certificates generated by the Security Gateway. As the Security Gateway functions as a Man-In-The-Middle (MITM) during HTTPS Inspection, it must sign certificates on-the-fly for outbound traffic.

This requires a CA certificate with the appropriate authority to issue certificates. Without a CA certificate, the Security Gateway cannot sign certificates, and Outbound HTTPS Inspection cannot work.

Note - Starting from R82, you can create or import more than one outbound CA certificate and manage them in SmartConsole.

Best Practice:

We recommend to configure the Security Gateway's outbound CA as a subordinate CA under an existing organizational CA.

This allows clients to automatically inherit the trust relationship from the root CA, eliminating the need to distribute the Security Gateway's CA certificate separately.

Instead, only the root CA certificate of the organization needs to be deployed to clients.

This setup with a subordinate CA simplifies the certificate management.

When it is necessary to replace the outbound CA certificate on the Security Gateway, the trust chain remains intact, as it relies on the root CA.

This minimizes administrative overhead and ensures a seamless transition during certificate updates.

Steps to configure the Security Gateway's Outbound CA as a Subordinate CA:

Note - If you already deployed an organization CA certificate, then start from Step "c".

  1. Generate a root CA certificate for your organization using your chosen Certificate Authority tool (e.g., OpenSSL, Microsoft CA, etc.). This root CA will serve as the trusted anchor for all subordinate CAs.

  2. Deploy the root CA certificate to all client devices to establish a trust relationship. This ensures clients recognize and trust any certificates issued by the subordinate CA.

  3. Generate a certificate signing request (CSR) for the subordinate CA. Use the root CA to sign this CSR, creating a subordinate CA certificate. Ensure the subordinate CA certificate includes the necessary extensions for signing other certificates (e.g., Basic Constraints and Key Usage).

  4. In SmartConsole, import the subordinate CA certificate.

    • Management Server versions R82 and higher:

      From the left navigation panel, click Security Policies > in the middle panel, in the HTTPS Inspection section, click Outbound Policy > from the top toolbar, click Outbound Certificates > click Import > select the subordinate CA certificate > enter the password > click OK.

Notes

  • You can also import this certificate in the Security Gateway object on the HTTPS Inspection page > in the section Step 1.

  • When importing a certificate, it is necessary to include all the intermediate CAs of the chain in the *.p12 file. Inclusion of only the server certificate or the intermediate CA certificate may cause some web browsers to warn about untrusted sites because some web browsers are unable to fetch and validate the complete certificate chain.

  1. Install the Access Control policy on the Security Gateway object to apply the new outbound CA configuration.

Note:

Making sure all intermediate certificates in the chain are signed with SHA-256 to avoid browser warnings

For both inbound and outbound HTTPS Inspection, validate that all intermediate certificates in the chain are signed with SHA-256 (or higher) algorithm.

Otherwise, browsers may warn (either by icon next to the URL, or in other ways) that the connection is not secure enough.

This limitation applies only to intermediate certificates in the chain, and not to root CAs.

(Part 2 - 3) Best Practices: Creating the HTTPS Inspection Rule Base

  1. Blocked Connections:

    If a connection is terminated based on the access rule-base, the HTTPS Inspection rule becomes irrelevant. Whether you have added a bypass rule or an inspection rule, in both cases, the connection is ultimately dropped due to the match with the access policy's default drop rule.

  2. What to Inspect

    We recommend to inspect HTTPS traffic from desktop browsers (Outbound HTTPS Inspection). Users may choose to bypass certain categories due to privacy considerations. Starting from R82, a default outbound rule is added to bypass finance, health and government categories in order to protect privacy rights. Non-browser HTTPS applications tend to trust their own root CA store and not to trust the certificate generated by the Security Gateway (examples: Google Drive, DropBox). In addition, non-browser HTTPS applications may use non-standard SSL and therefore cannot be inspected by the Security Gateway. These limitations are not specific to Check Point. It is possible to bypass these connections by Server IP address (when available), Client IP address (if there are few clients using these applications), or user identity. In cases the server uses standard SSL, bypass according to Category/URL can also be used. This is the recommended order for HTTPS Inspection Policy (Top-to-Down):

    1. IP-based Bypass rules with no site/category defined For more information, see sk163595.

  1. Bypass rules with site/category defined For more information, see sk165094.

  2. Inspect rules

  3. Inspection of sites with a multi-category certificate HTTPS Inspection bypass decisions are based on the server's certificate and client request. It is important to note that there are servers that issue a single certificate for several domains from different categories (Search Engines / Portals, Media Sharing, etc.). For example, see the Google certificate below:

  4. Services in the HTTPS Inspection rules In the HTTPS Inspection rule, in the Services column, we recommend to keep the default service object " HTTPS default services". If it is necessary to add other services, consult Check Point Support. Always select specific service objects in the 'Services' column. If you remove all services from this column, the Security Gateway starts to inspect all TCP traffic. As a result, CPU load increases.

  5. Bypassing Based on Client-Side Failures When client-side issues occur (for example, a connection is dropped because of a certificate-pinned application), future connections will be automatically bypassed. We recommend to identify the root cause of such issues and create an HTTPS Inspection Bypass rule for the specific application or destination. Alternatively, you can create an Access Control rule to block the application, if necessary. Client-side issues can also arise if the HTTPS Inspection Outbound CA is not deployed for the client's web browser. In such cases, properly deploying the CA will solve the issue.

To allow bypass without impact on user experience or privacy, it is necessary to determine the site's category without performing TLS decryption. To accomplish this, the site's category is resolved according to the SAN (Subject Alternative Name) or CN (Common Name) fields of server's certificate, and the SNI (Server Name Indication) TLS extension sent by the client. When the SNI extension isn't provided by the client, users should take into account that connections to servers that present the same server certificate may be matched to the same category.

(Part 2 - 4) Best Practices: Internet connection

Make sure the Security Gateway is connected to the Internet, either directly or through a proxy.

Proxy can be defined in the Security Gateway properties, or in the Global Properties.

If there is no Internet connection, then CRL fetch and intermediate CA fetch will fail (this will be logged).

The inspection will take place; however, URL-based or Category-based bypassing will not work.

Note: The CRL verifications are performed in the background asynchronously while matching the security policy (this mimics the behavior of the major web browsers).

Untrusted certificates and lack of CRLs can be configured as reasons to drop the connection:

Management Server versions R82 and higher:

Management Server versions R81.20 and lower:

Note about Bridge interfaces: In order for inspection to work properly, CRL validation is required. Therefore the Security Gateway must have an Internet connection in addition to the bridge interfaces.

(Part 2 - 5) Best Practices - Monitor TLS connections

Starting from R82, the HTTPS Inspection Statistics View allows you to monitor TLS traffic, providing clear view of Bypass and Inspect decisions. For more details, refer to How to use the HTTPS Inspection Statistics view.

(Part 3) Additional Information

(Part 3 - 1) Additional Information: Perfect Forward Secrecy Cipher Suites

(Part 3 - 2) Additional Information: Certificate-pinned Applications

Certificate-pinned applications, which are often non-browser clients, can face challenges with HTTPS Inspection. These certificate-pinned applications only trust specific server certificates. Therefore, importing the Security Gateway's CA certificate into the trust store on the client's operating system may not be enough to gain their trust. This can result in warnings or blocked traffic from these certificate-pinned applications.

To enhance security, we recommend to either restrict the traffic of such certificate-pinned applications using the Access Control policy or create HTTPS Inspection Bypass rules for traffic originating from devices that use these certificate-pinned applications or for the specific services, on which these applications depend.

Starting from R80.40, an Updatable Object is available to simplify the process of bypassing these certificate-pinned applications. Each applicable Updatable Object includes a list of HTTPS services known to be used in pinned-certificate scenarios. Additionally, a list of well-known HTTPS services used by popular programs and applications has been introduced and is recommended for HTTPS Inspection Bypass.

Starting from R82, several new features were added to further address the challenges posed by certificate-pinned applications:

For more information, refer to:

(Part 3 - 3) Additional Information: Update Services

Update services (such as Microsoft updates) are implicitly bypassed in the HTTPS Inspection rulebase.

(Part 3 - 4) Additional Information: Traffic over QUIC or HTTP/3

Inspecting traffic over QUIC or HTTP/3 is supported starting from R82.

In Security Gateway versions R81.20 and lower, we recommend to configure clients to use TLS instead, or reject such traffic to force them to use TLS.

For more information, refer to: sk111754 - HTTPS traffic to Google services (over QUIC) from Chrome cannot be inspected by HTTPS inspection rules

(Part 3 - 5) Additional Information: Categorized HTTPS vs. HTTPS Inspection

The "Categorize HTTPS websites" feature (in combination with URL Filtering) lets you categorize HTTPS sites without having to enable HTTPS Inspection.

When HTTPS Inspection is enabled, it also allows categorization for connections that are bypassed according the HTTPS Inspection rule base.

This feature does not perform inspection on the traffic and is only used to categorize sites so that URL Filtering rules can be enforced correctly.

Policies based on feature should consider that the confidence level in categorization is lower than that of HTTPS Inspection.

Similarly to HTTPS Inspection, the site's category is resolved according to the SAN (Subject Alternative Name) or CN (Common Name) fields of server's certificate, and the SNI (Server Name Indication) TLS extension sent by the client.

Note: Just like with HTTPS Inspection, make sure the Security Gateway is connected to the Internet, either directly or through a proxy.

A proxy server can be defined in the Security Gateway properties, or in the Global Properties.

(Part 3 - 6) HTTPS Inspection support for Post-Quantum Cryptography (PQC)

To help protect against "Harvest Now, Decrypt Later" cryptographic attacks, major web browsers have introduced support for quantum-safe algorithms, following recommendations by the National Institute of Standards and Technology (NIST).

This support is implemented in TLS 1.3 using a hybrid key exchange mechanism, which combines a classical public key cryptography algorithm (for example, ECDHE) with a post-quantum cryptography algorithm. Early implementations used CRYSTALS-Kyber algorithms as the quantum-safe component. In August 2024, NIST finalized the standardization of quantum-safe algorithms under the name ML-KEM and published it as FIPS 203. For more information, see sk182846.

(Part 4) Performance

HTTPS Inspection creates additional load on Security Gateway's CPU and increased RAM usage due to these reasons:

(Part 5) Debug

(Part 5 - 1) Debug: Notes

(Part 5 - 2) Debug: WSTLSD daemon

WSTLSD daemon handles SSL handshake for HTTPS Inspected connections.

Refer to sk105559 - How to debug WSTLSD daemon.

(Part 5 - 3) Debug: Firewall debug

Important Note: This kernel debug can cause very high load on Security Gateway's CPU.

Schedule a maintenance window.

  1. Prepare the debug:

    [Expert@HostName:0]# fw ctl debug 0

    [Expert@HostName:0]# fw ctl debug -buf 32000

    [Expert@HostName:0]# fw ctl debug -m fw + conn drop cptls

    [Expert@HostName:0]# fw ctl debug -m mux + tls

    From R80.40, you should also use:

    [Expert@HostName:0]# fw ctl debug -m crypto + all

  2. Verify the debug:

    [Expert@HostName:0]# fw ctl debug -m fw

    Output should show debugging buffer size 32000KB and all the debugging options enabled in the previous step.

  1. Start the debug: [Expert@HostName:0]# fw ctl kdebug -T -f > /var/log/debug.txt
  2. Capture the involved traffic:

    Refer to sk30583 - What is FW Monitor?. It might also be required to capture the traffic with TCPdump. 5. Replicate the issue: Make sure the issue was replicated. Collect all the relevant screenshots / logs that show the issue. 6. Stop the debug: Press CTRL+C and run [Expert@HostName:0]# fw ctl debug 0

  3. Collect these files:
    • /var/log/debug.txt
  • /var/log/messages*
  • traffic capture(s)
  • CPinfo file from the involved Security Gateway(s) / Cluster members
  • CPinfo file from the involved Security Management Server / Domain Management Server

(Part 5 - 4) Debug: HTTPS Inspection rulebase matching

Important Note: This kernel debug can cause very high load on Security Gateway's CPU.

Schedule a maintenance window.

  1. Prepare the debug:

    [Expert@HostName:0]# fw ctl debug 0

    [Expert@HostName:0]# fw ctl debug -buf 32000

    [Expert@HostName:0]# fw ctl debug -m fw + conn drop

    [Expert@HostName:0]# fw ctl debug -m NRB all

    [Expert@HostName:0]# fw ctl debug -m WS + connection info module pkt_dump policy session spii ssl_insp vs

  2. Verify the debug:

    [Expert@HostName:0]# fw ctl debug -m fw

    [Expert@HostName:0]# fw ctl debug -m NRB

    [Expert@HostName:0]# fw ctl debug -m WS

    Output should show debugging buffer size 32000KB and all the debugging options enabled in the previous step.

  3. Start the debug:

    [Expert@HostName:0]# fw ctl kdebug -T -f > /var/log/debug.txt 4. Capture the involved traffic:

    Refer to sk30583 - What is FW Monitor?. It might also be required to capture the traffic with TCPdump. 5. Replicate the issue: Make sure the issue was replicated. Collect all the relevant screenshots / logs that show the issue. 6. Stop the debug: Press CTRL+C and run [Expert@HostName:0]# fw ctl debug 0 7. Collect these files:

    • /var/log/debug.txt
    • /var/log/messages*
    • traffic capture(s)
    • CPinfo file from the involved Security Gateway(s) / Cluster members
    • CPinfo file from the involved Security Management Server / Domain Management Server

(Part 6) Related documentation

(Part 7) Related solutions

Note: These articles require "Advanced" access level or higer.

(Part 8) Revision history

| | |

| --- | --- | | Date | Description | | 06 Nov 2024 | - "Best Practices" section - "(Part 2 - 1) Best Practices: Configuring certificates" - split into two sections:
- (Part 2 - 1) Best Practices: Configuring inbound certificates
- (Part 2 - 2) Best Practices: Configuring outbound certificates | | 06 Nov 2024 | - "Best Practices" section - "(Part 2 - 2) Best Practices: Creating the HTTPS Inspection Rule Base" - add the step "Bypassing Based on Client-Side Failures"
- "Additional Information" section - "(Part 3 - 2) Additional Information: Certificate-pinned Applications" - updated the entire text | | 28 Feb 2023 | - Improved formatting of the article
- "Best Practices" section - "(Part 2 - 2) Best Practices: Creating the HTTPS Inspection Rule Base" - added "C. Services in the HTTPS Inspection rules" | | 19 June 2017 | - "Introduction" section - added "Content Awareness" to the list of Software Blades that support HTTPS Inspection | | 21 Mar 2017 | - "Introduction" section - "(Part 1 - 1) Outbound HTTPS Inspection" - added a note about certificate being validated only in case of inspection
- "Best Practices" section - "(Part 2 - 3) Internet connection" - added a note about CRL verifications being performed in the background
- "Additional Information" section - "(Part 3 - 4) Categorized HTTPS vs. HTTPS Inspection" - added a note about certificate being validated only in case of inspection | | 14 July 2016 | - "Related solutions" section - added related solution | | 22 May 2016 | - "Introduction" section - added "Threat Emulation" blade to the list of Software Blades that support HTTPS Inspection | | 31 Jan 2016 | - "Best Practices" section - "(Part 2 - 1) - B) CA creation/import" - added relevant steps for best practice, fastest deployment, and best security | | 10 Dec 2015 | - "Related solutions" section - added related solutions | | 18 Nov 2015 | - "Performance" section - added related solution (for Check Point Partners) | | 13 Nov 2015 | - "Related solutions" section - added related solutions | | 12 Nov 2015 | - First release of this article |

NOTE

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.

Article Properties

Access LevelGeneral

StatusApproved by TAC

Date Created2015-10-14

Last Modified2026-03-22