Support Center > Search Results > SecureKnowledge Details
What's new in HTTPS Inspection starting from R80.20 Technical Level

Starting in R80.20 and R80.30 latest Jumbo Hotfix Accumulators, HTTPS Inspection offers important new features in the domains of security and usability

To take advantage of these new capabilities, upgrade to R80.20 Jumbo Hotfix Accumulator Take 118 (and higher), or R80.30 Jumbo Hotfix Accumulator Take 111 (and higher).


  • Are you sure that the host you want to connect to is the one you will eventually connect to?

TLS connections will be validated in advance. Before the client passes the Security Gateway, we will verify that the client will eventually reach the correct destination and that the destination is trusted. The TLS Client indicates which hostname it is attempting to connect to at the start of the handshaking process, and we will match this hostname against the Subject Alternative Names in the host certificate. To make sure that the categorization is done according to the real destination host, and not the requested host, after matching the hostname we will verify the host certificate and make sure it is trusted.

This will let us make a reliable decision as to whether or not to trust the destination.

  • Are your connections categorized based on a reliable and validated hostname?

Our new categorization is based on the security described above, making the HTTPS traffic categorization more reliable than ever. After the validation of the destination, we will cache the result and use it for further categorization decisions.

This way, we will achieve secure categorization without affecting performance.

  • Are you concerned about TLS connectivity while inspection is turned on?

Now we can reliably determine in advance if we are able to inspect the connection. Before the client request makes its way to the server, we will open a new connection and will make a full, separate TLS handshake. During the separate handshake, we will collect enough information to know if we are able to inspect the connection or not.

This will let us reliably make the fail open/fail close decision.


SNI Background

Server Name Indication (SNI) is an extension of the TLS Protocol. The TLS Client indicates which hostname it is attempting to connect to at the start of the handshaking process. The SNI extension allows a server to present multiple certificates on the same IP address and TCP port number. This allows multiple secure websites (e.g., HTTPS) to be served by the same IP address.

Subject Alternative Name (SAN) is an extension to certificates that allows various values to be associated with a security certificate using a SubjectAltName entry.

Verifying the SNI field content - preventing HTTPS Inspection evasion techniques

The TLS 1.2 standard does not protect the content of the SNI field. Hackers use techniques to evade site categorization functionalities of Gateways performing HTTPS Inspection. Check Point Security Gateways make sure that the categorization is done according to the real destination host (the host responding to the TLS handshake), and not the requested host (the server name indicated in the SNI field).

How is this achieved?

At the start of the TLS handshaking process, the client sending the TLS Client Hello message indicates the hostname it is attempting to connect to by providing the server hostname as the content of the SNI field. The Security Gateway performs a probing operation which verifies that the hostname matches against the Subject Alternative Names found in the certificate presented by the responding host in the TLS Server Hello message. This verification process occurs before the server can actually send data to the client. The Security Gateway keeps a cache about the result of this verification process in order to save CPU cycles, traffic, and connection initialization latency of subsequent TLS connections are requested to the same destination site.

The probing operation is done using a separate TCP connection which originates from the Security Gateway's IP address. In addition, certificate validation is performed as part of the probing operation, including CRL and OCSP validation. Therefore, its connection must be allowed to reach the destination server and the CRL/OCSP distribution points of the certificates it validates.

Why is this important for the matching of the HTTPS Inspection policy?

In some cases, inspection should be bypassed. These are:

  • Privacy considerations: financial data, medical data, etc. 
  • Technical reasons: key pinning, client certificate usage, etc.

This method secures the matching process of the HTTPS Inspection policy when deciding to inspect or to bypass a connection. Note that the HTTPS Inspection policy decides only about inspecting (removing the encryption) or bypassing (leaving the connection encrypted). Decisions about blocking or allowing the traffic protected by the encryption are made by the Access Control and Threat Prevention policies. Using the verified SNI, categorization is accurate and reliable.

What is the site category role when matching the HTTPS Policy?

Most HTTPS Inspection policy rules use a category object to make decisions about inspecting or bypassing the traffic. This elevates the importance of site categorization and makes it very relevant to the security of the network protected by the Security Gateway.

Site categorization relies on the content of the SNI field sent in the TLS Client Hello and the content of the certificate presented in the TLS Server Hello.

The Security Gateway verifies the content of the TLS Client and the Server Hello packets (as explained above). Only if the server name can be verified will the site category be determined. This additional security verification makes HTTPS traffic categorization more reliable than ever. The result of the categorization is cached, thus saving CPU cycles, traffic, and connection initialization latency for subsequent categorization decisions.

Starting in R80.40, the inspection Rule Base will move to SmartConsole. Going forward, more HTTPS configuration settings will be moved to SmartConsole.

What are the verifications performed on the certificate presented in the TLS Server Hello?

The Security Gateway verifies the certificate presented in the TLS Server Hello against revocation lists, expiration date, and the public root certificate of the CA that has signed this presented certificate, the latter of which must be present in the Security Gateway's certificate storage.

You will see the configuration options for these functions in SmartDashboard's HTTPS Validation section.

What if the TLS Handshake might fail?

During a TLS Handshake, a situation can occur in which either the client or the server side is unable to complete the process. Reasons for this might be related to unsupported TLS cipher suites, or the server's requesting a client certificate for authentication when the client does not have one. When this happens, the Security Gateway acts according to the fail-mode option configuration defined in the SmartDashboard HTTPS Validation settings. Starting in R80.20 Jumbo Hotfix Accumulator Take 118 and later, a new handling method is available: it will safely handle these situations and bypass or drop the connections according to the configured option.

What's Next?

  • In R80.40, the HTTPS Inspection rulebase has been moved to SmartConsole. 
  • Bypassing well-known services: In order to effectively control and bypass well-known services, starting in R80.40 the administrator will be able to add an updatable whitelist to the Rule Base. 
  • TLS visibility: In order to effectively monitor the network, starting in R80.40 TLS alerts and important TLS events will be displayed in the Smart Log. 
  • Added support for TLS 1.3 protocol is on the road map for 2020 (see sk166715 for updates).
This solution has been verified for the specific scenario, described by the combination of Product, Version and Symptoms. It may not work in other scenarios.

Give us Feedback
Please rate this document