> Source: [sk104717](https://support.checkpoint.com/results/sk/sk104717)

# sk104717 - HTTPS Inspection Enhancements in R77.30, R80.10, and R80.20

| Property | Value |
|----------|-------|
| Solution ID | sk104717 |
| Date Created | 2015-02-12 |
| Last Modified | 2025-03-06 |
| Technical Level | General |
| Products | Security Gateway |
| Versions | R82.10, R82, R81.20 |
| OS | Gaia |

## Solution

**This SK is not relevant to R80.30 or higher versions. R80.30 has all of the below and more. To change what ciphers are used in R80.30 and higher, refer to [sk126613 - Cipher configuration tool for R80.x Gateways](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk126613).**

R77.30 introduces the following improvements and enhancements for HTTPS Inspection (which is supported on Security Gateways running only Gaia OS and SecurePlatform OS):

* SSL Handshake Acceleration
* Perfect Forward Secrecy (PFS)
* Support for AES-GCM
* Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass
* Passive HTTPS Inspection - HTTPS Inspection Test Mode

SSL Handshake Acceleration {#SSL Handshake Acceleration}
--------------------------------------------------------

*

  #### Overview

  > Public Key cryptographic operations, such as RSA and ECDH, require performing many mathematical operations, which causes a high load on CPU. By using the CPU's 64-bit instruction set, the operations can be done significantly faster than with 32-bit instructions.
  >
  > *PKXLD* is a 64-bit process that can run on a 64-bit operating system and perform the required cryptographic operations. It was added to achieve SSL handshake acceleration for HTTPS Inspection.
  >
  > Note: PKXLD process can *not* run on 32-bit operating system.
*

  #### Enabling and disabling the usage of PKXLD process

  > Usage of PKXLD process is enabled by default on Gaia 64-bit. The PKXLD process will be executed as needed by the WSTLSD process, if Gaia OS is running in 64-bit mode.
  >
  > |------------------|-----------------------------------------------------|-----------------------------------------------------|
  > | Gateway mode     | To disable SSL Handshake Acceleration               | To re-enable SSL Handshake Acceleration             |
  > | Security Gateway | # touch $FWDIR/conf/pkxl_disable # reboot           | # rm -i $FWDIR/conf/pkxl_disable # reboot           |
  > | VSX              | # vsenv 0 # touch $FWDIR/conf/pkxl_disable # reboot | # vsenv 0 # rm -i $FWDIR/conf/pkxl_disable # reboot |
  >
  > Notes:
  > * In VSX mode, the commands must be executed in the context of VSX Gateway itself (context of VS0), and affect *all* Virtual Systems.
  > * In cluster, the commands must be executed on *each* of the cluster members.  
  >   Note: You *are*allowed to have some cluster members with PKXLD enabled, and some cluster members with PKXLD disabled.

Perfect Forward Secrecy (PFS) {#Perfect Forward Secrecy (PFS)}
--------------------------------------------------------------

This section provides information about the **ECDHE** and **ECDSA** cipher suites.

*

  #### ECDHE cipher suites

  * Introduction

    > ECDHE cipher suites were added to Multi-Portals and HTTPS Inspection, providing PFS support for those two products.
    >
    > R77.30 adds support for the following cipher suites within HTTPS Inspection:
    > * `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` (ID 0x00C02B)
    > * `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` (ID 0x00C02F)
    > * `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` (ID 0x00C013)
    > * `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA` (ID 0x00C014)
    > * `TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA` (ID 0x00C009)
    > * `TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA` (ID 0x00C00A)
    >
    > R77.30 adds support for the following cipher suites within Multi-Portals (Software Blades Portals):
    > * `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` (ID 0x00C02F)
    > * `TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA` (ID 0x00C013)
    > * `TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA` (ID 0x00C014)
  * Configuration

    > Important Notes:
    > * The commands provided in this section must be run on Security Gateway / *each* cluster member in Expert mode.
    > * Before running the '`ckp_regedit`' command, backup the current Check Point Registry:  
    >   *[Expert@HostName:0]# cp -v $CPDIR/registry/HKLM_registry.data $CPDIR/registry/HKLM_registry.data_BKP*
    > * In VSX mode, the configuration is performed *per* Virtual System:  
    >   *[Expert@HostName:0]# vsenv <VSID>
    >   [Expert@HostName:0]# ckp_regedit ...*
    > * After running the `ckp_regedit` command, you must restart the Check Point services with the `cpstop;cpstart` commands. This stops all traffic, and in cluster might cause a failover.
    > * These commands survive reboot (changes are saved in Check Point Registry file - *$CPDIR/registry/HKLM_registry.data*).
    >
    > |----------------------------------------------------------|-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|
    > |                                                          | Design                                                                | To propose only ECDHE                                                                                                          | To disable ECDHE proposal                                            |
    > | HTTPS connection from Client machine to Security Gateway | By default, *ECDHE* is accepted, but *AES-GCM with RSA* is preferred. | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE 1`* Note: This will restrict the Client side to use ECDHE only | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDHE 2`*  |
    > | HTTPS connection from Security Gateway to Server         | *ECDHE* is proposed only if other proposals fail.                     | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE 1`*                                                           | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDHE 2`* |

  <br />

  <br />

*

  #### ECDSA cipher suites

  * Configuration

    > Important Notes:
    > * The commands provided in this section must be run on Security Gateway / *each* cluster member in Expert mode.
    > * Before running the `ckp_regedit` command, backup the current Check Point Registry:  
    >   *[Expert@HostName:0]# cp -v $CPDIR/registry/HKLM_registry.data $CPDIR/registry/HKLM_registry.data_BKP*
    > * In VSX mode, the configuration is performed *per* Virtual System:  
    >   *[Expert@HostName:0]# vsenv <VSID>
    >   [Expert@HostName:0]# ckp_regedit ...*
    > * After running the `ckp_regedit` command, you must restart the Check Point services with the `cpstop;cpstart` commands. This stops all traffic, and in cluster might cause a failover.
    > * These commands survive reboot (changes are saved in Check Point Registry file - *$CPDIR/registry/HKLM_registry.data*).
    >
    > |----------------------------------------------------------|------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------|
    > |                                                          | Design                                   | To propose only ECDSA                                                                                                          | To disable ECDSA proposal                                            |
    > | HTTPS connection from Client machine to Security Gateway | Detailed information will be added soon. | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDSA 1`* Note: This will restrict the Client side to use ECDSA only | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_ACCEPT_ECDSA 2`*  |
    > | HTTPS connection from Security Gateway to Server         | Detailed information will be added soon. | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDSA 1`*                                                           | *`# ckp_regedit -a SOFTWARE\\CheckPoint\\FW1 CPTLS_PROPOSE_ECDSA 2`* |

**Clarification: If both `accept_ECDHE` and `accept_ECDSA` are set to "force", only cipher suites that are both ECDHE and ECDSA are used. The priority between the `ECDHE_ECDSA` cipher suites is according to internal configuration.**

Support for AES-GCM {#Support for AES-GCM}
------------------------------------------

The following AES-GCM cipher suites are now supported with TLS 1.2 in Multi-Portals and HTTPS Inspection, improving throughput on platforms that support [AES-NI](http://en.wikipedia.org/wiki/AES_instruction_set) ^\*^:

* `TLS_RSA_WITH_AES_128_GCM_SHA256` (ID 0x00009C)
* `TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256` (ID 0x00C02B)
* `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` (ID 0x00C02F)

Notes:

* For detailed information about [AES-NI](http://en.wikipedia.org/wiki/AES_instruction_set) support, refer to [sk105119: Best Practices - VPN Performance](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk105119).
* On platforms that do not support AES-NI, AES-GCM is similar in performance to AES-CBC + HMAC-SHA1.

Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass {#Improvements in HTTPS Inspection Bypass mechanism}
---------------------------------------------------------------------------------------------------------------------

**This section is irrelevant for R80.30 and higher, since a new probe mechanism was introduced (enabled by default) - customer should NOT use the 'old' mechanism (*enhanced_ssl_inspection*).**

**Important Note: Probe Bypass should *not* be used if there is a proxy between the Security Gateway and the Internet.**

Limitations of HTTPS Inspection Bypass Mechanism *without* Probe Bypass:

* Every first connection to a site is inspected even if it should have been bypassed according to the policy.
* Non-Browser Applications connections are dropped when HTTPS Inspection is enabled (even if bypass is configured).
* Client certificate connections are dropped when HTTPS Inspection is enabled (even if bypass is configured).

Improvements introduced by Probe Bypass:

* Bypass mechanism was improved to better reflect policy and resolve the limitations listed above:  
  * Stop the inspection of the first connection to bypassed sites.
  * Allow bypass of Non-Browser Applications connections.
  * Allow Bypass of connections to servers that require client certificate.
* New probing mechanism eliminates the need to inspect the first connection to an IP address unless it is required by the policy.

Limitations of HTTPS Inspection Bypass Mechanism *with enabled* Probe Bypass:

* HTTPS Inspection does not work for sites that require SNI (Server Name Indication) extension in the SSL "Client hello" packet. (Server Name Indication is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshake process.)

Status of Improved HTTPS Inspection Bypass feature (Probe Bypass) is controlled by the value of kernel parameter ***enhanced_ssl_inspection***:
>
> |-------|--------------------------------------------|
> | Value | Explanation                                |
> | 0     | Default value. Probe Bypass is *disabled*. |
> | 1     | Probe Bypass is *enabled*.                 |
> | **Note: For R80.30 and higher, value should be "0", since a new probe mechanism was introduced in these versions.** ||

**Note:** The steps below affect all Virtual Systems in VSX mode.

To ***enable*** the Improved HTTPS Inspection Bypass feature (Probe Bypass) on Security Gateway / *each* cluster member, set the value of kernel parameter ***enhanced_ssl_inspection*** to **1**.

* To check the current value of a kernel parameter:

  **`[Expert@HostName]# fw ctl get int enhanced_ssl_inspection`**
* To set the desired value for a kernel parameter *on-the-fly* (does not survive reboot):

  **`[Expert@HostName]# fw ctl set int enhanced_ssl_inspection 1`**
* To set the desired value for a kernel parameter *permanently*:

  Follow [sk26202 (Changing the kernel global parameters for Check Point Security Gateway)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk26202).
  1. Create the `$FWDIR/boot/modules/fwkern.conf` file (if it does not already exit):

     **`[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf`**
  2. Edit the `$FWDIR/boot/modules/fwkern.conf` file in Vi editor:

     **`[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf`**
  3. Add the following line (spaces and comments are not allowed):

     **`enhanced_ssl_inspection=1`**
  4. Save the changes and exit from Vi editor.

  5. Check the contents of the `$FWDIR/boot/modules/fwkern.conf` file:

     **`[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf`**
  6. Reboot the Security Gateway / *each* cluster member.

To ***disable*** the Probe Bypass on Security Gateway / *each* cluster member, follow the steps above to set the value of kernel parameter ***enhanced_ssl_inspection*** to **0**.

In addition, refer to:

* [sk107744 - Unable to access some HTTPS sites after enabling HTTPS Inspection "Probe Bypass" mechanism](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk107744)

**Important:**

* In R80.10, before Jumbo Hotfix Accumulator for R80.10 Take 189, the probing feature is set, by default, to Fail Open.
* From Take 189, the default behavior is changed to Fail Close.
* You can return to the behavior as it was before Take 189, by setting `bypass_on_enhanced_ssl_inspection 1`

**To set the default to Fail Open:**

1. Run: `fw ctl set int bypass_on_enhanced_ssl_inspection 1`
2. In `$FWDIR/modules/fwkern.conf`, add this line: `bypass_on_enhanced_ssl_inspection=1`

**The probing feature may fail in the following scenarios (and therefore it is not recommended):**

* Server requires an SNI extension in the SSL "Client hello" packet.
* Missing cipher - The Security Gateway does not support any of the server allowed ciphers.
* The server presents an incorrect certificate when SNI is not provided

**To disable probing (Recommended):**

1. Run: `fw ctl set int enhanced_ssl_inspection 0`
2. In `$FWDIR/modules/fwkern.conf`, add this line: `enhanced_ssl_inspection=0`

HTTPS Inspection Test Mode {#Passive HTTPS Inspection - HTTPS Inspection Test Mode}
-----------------------------------------------------------------------------------

*

  #### Background

  > Under full HTTPS Inspection test load, the CPU usage of the Security Gateway is well under 100%.
  >
  > Performance measurements performed by testing equipment (such as Avalanche and Breaking Point) such as CPS, showed that throughput and latency behave irregularly.
*

  #### Cause

  > The cause for this irregularity is non-standard HTTPS implementation by the testing equipment in order to improve capacity and performance.
  >
  > Check Point's Active Inspection follows *standard* HTTPS.
*

  #### Solution

  > Passive HTTPS Inspection (HTTPS Inspection Test Mode) solves interoperability issues with testing equipment.
  >
  > However, it is important to note these limitations:
  > * Intended *only* for lab use.
  > * Supports inspection of inbound traffic.
  > * Supports detection only - should be used *only* for testing purposes.
  > * Performance results measured in Test Mode may slightly differ from real-world results.
  > * ECDHE cipher suites can *not* be used in Test Mode because Passive decryption does *not* support PFS.
*

  #### Configuration of HTTPS Inspection Test Mode

  > Status of HTTPS Inspection Test Mode is controlled by the value of kernel parameter ***fwtls_passive_decrypt***:
  >
  > |-------|-----------------------------------------|
  > | Value | Explanation                             |
  > | 0     | Default value. Test Mode is *disabled*. |
  > | 1     | Test Mode is *enabled*.                 |
  >
  > **Note:** The steps below must be performed *before* the machine is placed under traffic load. If Test Mode is enabled *during* traffic load, existing connections may be dropped.
  > * To ***enable*** the Test Mode on Security Gateway / *each* cluster member, set the value of kernel parameter ***fwtls_passive_decrypt*** to **1**.
  >
  >   * To check the current value of a kernel parameter:
  >
  >     **`[Expert@HostName]# fw ctl get int fwtls_passive_decrypt`**
  >   * To set the desired value for a kernel parameter *on-the-fly* (does not survive reboot):
  >
  >     **`[Expert@HostName]# fw ctl set int fwtls_passive_decrypt 1`**
  >   * To set the desired value for a kernel parameter *permanently* (***not* recommended**):
  >
  >     Follow [sk26202 (Changing the kernel global parameters for Check Point Security Gateway)](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk26202).
  >     1. Create the `$FWDIR/boot/modules/fwkern.conf` file (if it does not already exit):
  >
  >        **`[Expert@HostName]# touch $FWDIR/boot/modules/fwkern.conf`**
  >     2. Edit the `$FWDIR/boot/modules/fwkern.conf` file in Vi editor:
  >
  >        **`[Expert@HostName]# vi $FWDIR/boot/modules/fwkern.conf`**
  >     3. Add the following line (spaces and comments are not allowed):
  >
  >        **`fwtls_passive_decrypt=1`**
  >     4. Save the changes and exit from Vi editor.
  >
  >     5. Check the contents of the `$FWDIR/boot/modules/fwkern.conf` file:
  >
  >        **`[Expert@HostName]# cat $FWDIR/boot/modules/fwkern.conf`**
  >     6. Reboot the Security Gateway / *each* cluster member.
  >
  > * To ***disable*** the Test Mode on Security Gateway / *each* cluster member, follow the steps above to set the value of kernel parameter ***fwtls_passive_decrypt*** to **0**.

*

  #### Additional configuration for Session Rate optimization in HTTPS Inspection Test Mode

  > To optimize the Session Rate in HTTPS Inspection Test Mode, increase the maximal number of entries in the following kernel tables:
  > * `fwtls_state_map`
  > * `cptls_sessions`
  >
  > Follow these steps:
  >
  > **Important Note:** These changes affect *all* Security Gateway / Clusters managed by the involved Security Management Server / Multi-Domain Security Management Server.
  > 1. Connect with SmartDashboard to Security Management Server / Domain Management Server.
  >
  > 2. Go to the **`File`** menu and click `Database Revision `**Control...** and create a revision snapshot.
  > 3. Close all SmartConsole windows (SmartDashboard, SmartView Tracker, SmartView Monitor, etc.).
  >
  > 4. Connect to command line on Security Management Server / Multi-Domain Security Management Server.
  >
  > 5. On the Multi-Domain Security Management Server, switch to the context of the involved Domain Management Server:
  >
  >    **`[Expert@HostName]# mdsenv `*Domain_Name***
  > 6. Backup and edit the relevant ***table.def*** file per [sk98339 - Location of 'table.def' files on Security Management Server](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk98339).
  >
  > 7. Change:
  >
  >    from
  >    >
  >    > ```
  >    > /*********
  >    >  * fwtls *
  >    >  *********/
  >    > 
  >    > fwtls_state_map = dynamic keep limit 100000 hashsize 32768;
  >    > cptls_sessions = dynamic expires 3600 limit 100000 hashsize 32768 sync kbuf 2;
  >    > ```
  >
  >    to
  >    >
  >    > ```
  >    > /*********
  >    >  * fwtls *
  >    >  *********/
  >    > 
  >    > fwtls_state_map = dynamic keep limit 1000000 hashsize 32768;
  >    > cptls_sessions = dynamic expires 600 limit 1000000 hashsize 32768 sync kbuf 2;
  >    > ```
  >
  > 8. Save the changes in the relevant *table.def* file.
  >
  > 9. Connect with SmartDashboard to Security Management Server / Domain Management Server.
  >
  > 10. Install the policy on the relevant Security Gateway / Cluster object.

### Related solutions:

* [sk108202 - Best Practices - HTTPS Inspection](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk108202)
* [sk104562 - Supported cipher suites for HTTPS Inspection](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk104562)
* [sk101223 - MultiCore Support for SSL](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk101223)
* [sk107744 - Unable to access some HTTPS sites after enabling HTTPS Inspection "Probe Bypass" mechanism](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk107744)
* [sk64162 - "Internal System Error occurred" log when URL Filtering blocks HTTPS traffic while trying to categorize HTTPS resources](https://support.checkpoint.com/results/sk/sk64162)

---

# Agent Instructions

This content is from the Check Point Support Center (https://support.checkpoint.com), the official knowledge base for Check Point cybersecurity products.

## Navigating This Knowledge Base

- **Complete index**: [llms.txt](https://support.checkpoint.com/llms.txt)
- **All SK articles**: [SecureKnowledge Sitemap](https://support.checkpoint.com/sitemaps/secureknowledge-sitemap-index.xml)
- **SK article URL pattern**: `https://support.checkpoint.com/results/sk/{skId}`
- **Markdown responses**: AI bot User-Agents automatically receive `text/markdown` content