Support Center > Search Results > SecureKnowledge Details
Best Practices - HTTPS Inspection Technical Level
Solution

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

Note: To benefit from the latest improvements in security, performance and stability, Check Point always recommends to upgrade to the most recent version (upgrade Security Gateway / upgrade Cluster / upgrade VSX / upgrade 600 appliance / upgrade 1100 appliance / upgrade Security Management Server / upgrade Multi-Domain Security Management Server / upgrade SmartConsole).

 

Table of Contents:

  1. Introduction
    1. HTTPS Inspection - Inbound vs. Outbound
    2. Gradual Deployment
    3. Initial configuration
  2. Best Practices
    1. Configuring certificates
    2. Creating the HTTPS Inspection Rule Base
    3. Internet connection
  3. Additional Information
    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
  4. Performance
  5. Debug
    1. Notes
    2. WSTLSD daemon (TLS handshake)
    3. Firewall debug
    4. HTTPS Inspection rulebase matching
  6. Related documentation
  7. Related solutions
  8. Revision history

 

(I) 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 it is recommended 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:

  • Application Control
  • URL Filtering
  • IPS
  • Data Loss Prevention (DLP)
  • Anti-Virus
  • Anti-Bot
  • Threat Emulation
  • Content Awareness

 

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

  • Inbound HTTPS Inspection protects internal servers (for example, data centers and web servers) from malicious attacks coming from the Internet.

    Inbound connections are HTTPS connections that start from an external client and connect to an internal server in the DMZ or the network. The Security Gateway compares the HTTPS request to the HTTPS Inspection Rule Base. If the request does not match a rule, the packet is not decrypted.

    If the request matches an inspection rule, the Security Gateway uses the certificate for the internal server to create a HTTPS connection with the external client. The Security Gateway creates a new HTTPS connection with the internal server. Since the Security Gateway has a secure connection with the external client, it can decrypt the HTTPS traffic. The decrypted traffic is inspected according to the policy.

    Flow on Security Gateway:

    1. Intercept the request.
    2. Use the server's original certificate and private key to initiate a TLS connection with the client.
    3. Create and establishes a new TLS connection with the web server.
    4. Using the two TLS connections:
      1. Decrypt the encrypted data from the client.
      2. Inspect the clear text content for all blades set in the policy.
      3. Encrypt the data again to keep client privacy as the data travels to the destination server behind the Security Gateway.

  • Outbound HTTPS Inspection protects internal users and perimeter servers from malicious attacks coming from the Internet on connections originated from inside the organization.

    Outbound connections are HTTPS connections that start from an internal client and connect to the Internet. The Security Gateway compares the HTTPS request to the HTTPS Inspection Rule Base. If the request does not match a rule, the packet is not decrypted.

    If the request matches an inspection rule, the Security Gateway makes sure that the certificate from the server (in the Internet) is valid. The Security Gateway creates a new certificate, and presents it to the client, when the client creates an HTTPS connection to the gateway. There are two HTTPS connections, one to the internal client and one to the server. It can then decrypt and inspect the packets according to the Security Gateway and other Rule Bases. The packets are encrypted again and sent to the destination.

    Flow on Security Gateway:

    1. Intercept the request.
    2. Establish a secure connection with the requested server and validate its certificate using a separate probing connection.
    3. Make an inspection or bypass decision based on the rule matched using information gathered from the original connection and server certificate.
    4. When a decision to inspect is made, establish a secure connection with the requested server.
    5. Create a new TLS certificate for the communication between the Security Gateway and the client, send the client the new certificate and continue the TLS negotiation with it.
    6. Using the two TLS connections:
      1. Decrypt the encrypted data received.
      2. Inspect the clear text content for all blades set in the Policy.
      3. Inspect the traffic coming from the web site into the organization.
      4. Encrypt the data again to keep client privacy as the data travels to the destination web server resource.

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

 

(I-2) Introduction: Gradual Deployment

When first enabling HTTPS Inspection, it is recommended to use a gradual approach. Starting with few Security Gateways and networks, and expanding 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. HTTPS Inspection can be enabled on a single Security Gateway at first, and then expanded to additional Security Gateways.

 

(I-3) Introduction: Initial configuration

Refer to R80.30 Next Generation Security Gateway Guide - Chapter "Creating Shared Policies" - "Configuring HTTPS Inspection".

 

(II) Best Practices

(II-1) Best Practices: Configuring certificates

  1. Using the entire certificate chain for configuring inspection of incoming traffic

    When importing an internal server's certificate for incoming 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.

     

  2. CA creation/import - Using a CA certificate for HTTPS Inspection of outgoing traffic

    When importing an external certificate in SmartDashboard on the - "Advanced" - "HTTPS Inspection" - "Gateways" - "Import Certificate from file...", it is imperative to use a CA certificate, so that this certificate can be used to sign certificates generated by Security Gateway for outgoing traffic inspection.

    Importing a non-CA certificate will result in client browsers refusing the connection.

    Notes:

    • The administrator may generate a CA certificate from the Security Gateway properties - "HTTPS Inspection".
      That CA certificate will be used to sign the certificates generated by Security Gateway.

    • The best practice would be:

      • 1) deploy this certificate on the entire organization (usually through GPO for Windows domain)
      • 2) export a CA certificate from an existing CA of the organization
      • 3) sign a new CA certificate from an existing CA of the organization
    • For fastest deployment, the order should be (because computers should probably already use the organization CA):

      • 3) sign a new CA certificate from an existing CA of the organization
      • 2) export a CA certificate from an existing CA of the organization
      • 1) deploy this certificate on the entire organization (usually through GPO for Windows domain)
      OR
      • 2) export a CA certificate from an existing CA of the organization
      • 3) sign a new CA certificate from an existing CA of the organization
      • 1) deploy this certificate on the entire organization (usually through GPO for Windows domain)
    • For best security, the order should be:

      • 3) sign a new CA certificate from an existing CA of the organization
      • 1) deploy this certificate on the entire organization (usually through GPO for Windows domain)
      • 2) export a CA certificate from an existing CA of the organization


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

    For both incoming and outgoing 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.

 

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

  1. What to Inspect

    It is highly recommended to inspect HTTPS traffic from desktop browsers (Outbound HTTPS Inspection).

    Users may choose to bypass certain categories due to privacy considerations.
    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.

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

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.

(II-3) 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:

Note: Checking the box "Log connections of clients that have not installed the CA certificate" will log connections of clients that have not installed the CA certificate, however it will also log other cases of dropped connections. It is recommended to clear this box.

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.

 

(III) Additional Information

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

  • Perfect Forward Secrecy (PFS) - introduction

    Perfect Forward Secrecy (PFS) is a key agreement method that saves the need of transferring shared secrets on the wire, thus guaranteeing secrecy in the future, even if the traffic is recorded in the present.

    PFS is widely used in TLS and IKE/IPsec.
  • Perfect Forward Secrecy (PFS) - ECDHE

    Diffie-Hellman (DH) has been the traditional PFS algorithm.

    Elliptic curve Diffie-Hellman (ECDH) is a modern PFS algorithm based on Elliptic Curve computations. Same security level of Diffie-Hellman is achieved with much shorter keys in ECDH, so performance is much better.

    ECDHE is a protocol that uses Ephemeral ECDH keys.

    Some Web servers only accept PFS ciphers (DHE, ECDHE).

    ECDHE is fully supported in these versions of Security Gateway (ID 01418393):

For more information, refer to:

Note: Some web servers do not accept any of the Security Gateway's proposals. Connections to such web servers will fail without a log. If you encounter such issue, then contact Check Point Support for assistance.

 

(III-2) Additional Information: Certificate-pinned Applications

Certificate-pinned applications (often non-browser clients) may not work well with HTTPS Inspection. Such mobile or desktop applications trust only specific server certificates, and so importing the Security Gateway’s CA certificate into the system trust store will not be sufficient to get them to trust it.

Some applications would produce warnings in such a case, and others simply block the traffic.

It is recommended to either restrict such applications’ traffic for better security, or to create bypass rules for traffic originating from devices utilizing such applications or for the specific services that they rely upon.

Since R80.40, an Updatable Object was introduced to ease the process of bypassing such applications. It contains a list of HTTPS services that are known to be used in pinned-certificate scenarios.

For more information, refer to:

 

(III-3) Additional Information: Update Services

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

 

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

Inspecting traffic over QUIC or HTTP/3 is not supported yet. It is recommended 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

 

(III-4) 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.
 

(IV) Performance

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

TLS termination, encrypt/decrypt and active TCP termination. 
Additional traffic is inspected by security blades. In general, the more blades and security features, the higher the additional load.  

(V) Debug

(V-1) Debug: Notes

  • Always schedule a maintenance window to run any debug session.

  • Contact Check Point Support to get exact debug instructions specific to your case.

  • In cluster environment, debug must be collected on all members of the cluster.

  • To decrease the load on Security Gateway's CPU, the kernel debug can be started only on specific CoreXL FW Instances only.
    The safest way to do so is by starting the kernel debug on CoreXL FW Instance 0:
    # fw ctl debug 0
    # fw ctl debug -buf 32000
    # fw ctl debug -m MODULE + FLAGS
    # fw -i 0 ctl kdebug -T -f > /var/log/debug.txt

  • Refer to Next Generation Security Gateway R81 Administration Guide "Kernel Debug Modules and Debug Flags" section.

 

(V-2) Debug: WSTLSD daemon

WSTLSD daemon handles SSL handshake for HTTPS Inspected connections.

Refer to sk105559 - How to debug WSTLSD daemon.

 

(V-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 

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

 

(V-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

 

 

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

 

(VIII) Revision history

Date Description
19 June 2017
  • "Introduction" section - added "Content Awareness" to the list of Software Blades that support HTTPS Inspection
21 Mar 2017
  • "Introduction" section - "(I-1) Outbound HTTPS Inspection" - added a note about certificate being validated only in case of inspection
  • "Best Practices" section - "(II-3) Internet connection" - added a note about CRL verifications being performed in the background
  • "Additional Information" section - "(III-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 - "(II-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

Give us Feedback
Please rate this document
[1=Worst,5=Best]
Comment