HTTPS Inspection Enhancements

Support Center > Search Results > SecureKnowledge Details

Technical Level

Solution ID	sk104717
Technical Level
Product	HTTPS Inspection
Version	R77.30 (EOL), R80.10 (EOL), R80.20 (EOL)
OS	Gaia
Platform / Model	All
Date Created	19-May-2015
Last Modified	18-May-2022

Solution

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

This sk is not relevant to R80.30

Note: R80.30 has all of the below and more. To change what ciphers are used in R80.30, refer to sk126613 - Cipher configuration tool for R80.x Gateways.

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)

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

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

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 ^*:

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 support, refer to sk105119: Best Practices - VPN Performance.
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

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

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:

Run: fw ctl set int bypass_on_enhanced_ssl_inspection 1
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):

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

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

SSL Handshake Acceleration

Overview

Enabling and disabling the usage of PKXLD process

Perfect Forward Secrecy (PFS)

ECDHE cipher suites

ECDSA cipher suites

Support for AES-GCM

Improvements in HTTPS Inspection Bypass mechanism - Probe Bypass

HTTPS Inspection Test Mode

Background

Cause

Solution

Configuration of HTTPS Inspection Test Mode

Additional configuration for Session Rate optimization in HTTPS Inspection Test Mode

Related solutions: