Support Center > Search Results > SecureKnowledge Details
HTTPS Inspection Enhancements in R77.30 and above
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

 

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 in order 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 have to be executed in the context of VSX Gateway itself (context of VS0), and will affect all Virtual Systems.
    • In cluster, the commands need to be executed on each of the cluster members.
      Note: It is 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, it is mandatory to restart the Check Point services with the 'cpstop;cpstart' commands,
        which will stop all traffic, and in cluster might cause a fail-over.
      • 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, it is mandatory to restart the Check Point services with the 'cpstop;cpstart' commands,
        which will stop all traffic, and in cluster might cause a fail-over.
      • 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:

  • AES-NI is supported by Check Point 3200 / 5600 / 5800 / 12400 / 12600 / 13x00 / 15x00 / 21x00 / 23x00 / 41000 / 61000 appliances and by some Open Servers (refer to server's CPU specifications).
    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

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 above limitations:
    • 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 will not work for sites that require SNI extension in the SSL "Client hello" packet.
    Note: There is now a hotfix for Probe Bypass and sites that uses SNI (for R80.10). You will need to contact your SE and open a Request for Enhancement to receive it.

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: The steps below will 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:

 

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

  • 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 have to 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 will 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 'File' menu - click on 'Database Revision Control...' - 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 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 onto the relevant Security Gateway / Cluster object.

 

Related solutions:

Applies To:
  • 01418393 , 01456436 , 01467522 , 01470952 , 01471765 , 01474667 , 01479662 , 01510285 , 01516601 , 01522323 , 01546352 , 01551219 , 01556280 , 01577129
  • 01482072

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