Support Center > Search Results > SecureKnowledge Details
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.

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. Mobile Applications
    3. Update Services
    4. Categorized HTTPS vs. HTTPS Inspection
  4. Performance
  5. Debug
    1. Notes
    2. WSTLSD daemon (SSL handshake)
    3. HTTPS Inspection related issues
    4. HTTPS Inspection rulebase matching
  6. Related documentation
  7. Related solutions
  8. Revision history

 

(I) Introduction

HTTPS Internet traffic uses the 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 SSL 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 an SSL connection with the client.
    3. Create and establishes a new SSL connection with the web server.
    4. Using the two SSL 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 to the requested web site and validate the site server's certificate.
      Note: The certificate is validated only in case of inspection. In case of bypass, such validation is not performed (cached values from previous validation are used instead). 
    3. Create a new SSL certificate for the communication between the Security Gateway and the client, send the client the new certificate and continue the SSL negotiation with it.
    4. Using the two SSL connections:
      1. Decrypt the encrypted data from the client.
      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 added to 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 Application Control and URL Filtering Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) - Chapter "Managing Application Control and URL Filtering" - "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 blade's tab - "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.

    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:

    Without SSL decryption, there is no way for the Security Gateway to know the underlying URL and easily categorize the connection.

    Yet, in order to enable bypass rules of HTTPS Inspection, it is necessary to determine the site's category without SSL decryption - site category is resolved according to the FQDN of server's certificate.

    This is a trade-off between usability, connectivity and security, since there are sites that offer many services behind a single certificate, thus sharing the same FQDN among multiple categories.

    Therefore, the Site Category is determined by the certificate FQDN and the IP address, which presented the certificate, and should take into account the entire list of servers, which will be bypassed/inspected.

    Every connection to servers, which display such a multi-purpose certificate, will be categorized in the same way - the rulebase decision to inspect or bypass a connection will be made according to the category matched to the FQDN of the certificate.

    Let us examine the following rulebase:

    Since YouTube and Google Search present the same certificate - the connections to both sites will be matched as if they are both categorized as "Search Engines" - the bypass rule of YouTube will be ignored.

    Therefore, users should take into account that in certain cases, the connections will be matched according to the category of the FQDN.

 

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

Hote: 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 Security Gateways R77.20 and lower, connections to such web servers will fail without a log. An example of such a web server is tumblr.com.

    If you encounter such issue, then Contact Check Point Support to get a Hotfix from sk104717 (Issue ID 01418393).
    A Support Engineer will make sure the Hotfix is compatible with your environment before providing the Hotfix.
    For faster resolution and verification, please collect CPinfo files from the Security Management Server and Security Gateways involved in the case.

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: Mobile Applications

Mobile Applications (non-browser clients) and Mobile browsers do not work well with HTTPS Inspection. These clients cannot be forced to trust the Security Gateway's Certificate Authority (CA).

Some applications produce warnings, and others simply block the traffic.

It is recommended to either restrict mobile applications traffic for better security, or to create bypass rules for traffic originating from mobile devices (according to Wi-Fi Access Point's IP address, for example).

 

(III-3) Additional Information: Update Services

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

 

(III-4) Additional Information: Categorized HTTPS vs. HTTPS Inspection

Starting in R76, "Categorize HTTPS sites" feature (in combination with URL Filtering) lets you categorize a HTTPS site without activating HTTPS inspection to determine the content of the traffic, based on the FQDN of the server's certificate (SmartDashboard - go to "Application & URL Filtering" tab - in the left pane, go to "Advanced" - go to "Engine Settings" - in the "URL Filtering" section, check the box "Categorize HTTPS sites").

"Categorize HTTPS sites" feature does not perform inspection on the traffic. Policy, based upon the categorized inspection, should take into account that the confidence level is lower than that of HTTPS Inspection.

When the "Categorize HTTPS sites" option is enabled:

  1. The server's certificate is detected and validated
    Note: The certificate is validated only in case of inspection. In case of bypass, such validation is not performed (cached values from previous validation are used instead). 
  2. If the server is trusted, then the DN is extracted from the certificate
  3. The DN is used to categorize the site

The Categorize HTTPS sites option does not run if:

  • HTTPS Inspection is enabled
  • There is a proxy between the destination site and the Security Gateway (or the Security Gateway functions as a proxy)

 

(IV) Performance

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

  • SSL termination, encrypt/decrypt and active TCP termination that consume CPU resources (Note: The SSL handshake rate was significantly improved in R77.30 - refer to sk103081 and to sk104717).
  • Additional traffic is inspected by the security blades.

It is possible to approximate the effect of HTTPS Inspection activation under the following disclaimers:

  1. Representing a typical, outbound configuration (low or none inbound HTTPS Inspection traffic) with 36% HTTPS.
  2. Using R77.30 with either NGTP (Firewall, IPS, Application Control, URL Filtering, Anti-Virus, and Anti-Bot), or NGFW (Firewall, IPS and Application Control) software blades for inspection.
  3. Data Center scenario requires specific modeling.

The rational is that under the disclaimers written above, the impact on required Security Power (SPU) is 60% to 100% higher depending on the enabled software blades (the more blades are already enabled, the smaller the additional impact of HTTPS Inspection will be).

Therefore, when enabling HTTPS Inspection in an existing configuration, the CPU utilization on Security Gateway is expected to increase:

  • by factor of 1.6 for NGTP configuration
  • by factor of 2 for NGFW configuration

 

(V) Debug

(V-1) Debug: Notes

  • Always schedule a maintenance window to run any debug.

  • 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 Kernel Debug flags (R75.40VS, R76, R77, R77.10, R77.20, R77.30, R80.10)

 

(V-2) Debug: WSTLSD daemon

WSTLSD daemon handles SSL handshake for HTTPS Inspected connections.

Refer to sk105559 - How to debug WSTLSD daemon.

 

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

 

  • Firewall Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) - Chapter "Defining an Internet Access Policy" - "HTTPS Inspection"

  • Application Control and URL Filtering Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) - Chapter "Managing Application Control and URL Filtering" - "HTTPS Inspection"

  • Data Loss Prevention Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) - Chapter "Installation and Configuration" - "HTTPS Inspection"

  • IPS Administration Guide (R75.20, R75.40, R75.40VS, R76, R77) - Chapter "Monitoring Traffic" - "HTTPS Inspection"

  • Threat Prevention Administration Guide (R76, R77) - Chapter "Using Threat Prevention with HTTPS Traffic"

  • Anti-Bot and Anti-Virus Administration Guide (R75.40, R75.40VS) - Chapter "Managing Anti-Bot and Anti-Virus" - "HTTPS Inspection"

 

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