HTTPS Inspection

Outbound HTTPS Connections

Outbound connections are HTTPS connections that arrive from an internal client and connect to an external server.

Outbound connection flow

1. An HTTPS request (from an internal client to an external server) arrives at the Security Gateway.

2. The Security Gateway inspects the HTTPS request.

3. The Security Gateway determines whether the HTTPS request matches an existing HTTPS Inspection rule Set of traffic parameters and other conditions in a Rule Base (Security Policy) that cause specified actions to be taken for a communication session.:

   • If the HTTPS request does not match a rule, then the Security Gateway does not inspect the HTTPS payload.

   • If the HTTPS request matches a rule, then the Security Gateway continues to the next step.

4. The Security Gateway validates the HTTPS certificate from the external server.

   The Security Gateway uses the Online Certificate Status Protocol (OCSP) standard.

5. The Security Gateway creates a new certificate for the connection to the external server.

6. The Security Gateway decrypts the HTTPS connection.

7. The Security Gateway inspects the decrypted HTTPS connection.

8. If the Security Policy Collection of rules that control network traffic and enforce organization guidelines for data protection and access to resources with packet inspection. allows this traffic, the Security Gateway encrypts the HTTPS connection.

9. The Security Gateway sends the HTTPS request to the external server.

Inbound HTTPS Connections

Inbound connections are HTTPS connections that arrive from an external client and connect to a server in the DMZ or the internal network.

Inbound connection flow

1. An HTTPS request (from an external client to an internal server) arrives at the Security Gateway.

2. The Security Gateway inspects the HTTPS request.

3. The Security Gateway determines whether the HTTPS request matches an existing HTTPS Inspection rule:

   • If the HTTPS request does not match a rule, then the Security Gateway does not inspect the HTTPS payload.

   • If the HTTPS request matches a rule, then the Security Gateway continues to the next step.

4. The Security Gateway uses the certificate for the internal server to create an HTTPS connection with the external client.

5. The Security Gateway creates a new HTTPS connection with the internal server.

6. The Security Gateway decrypts the HTTPS connection.

7. The Security Gateway inspects the decrypted HTTPS connection.

8. If the Security Policy allows this traffic, the Security Gateway encrypts the HTTPS connection and sends it to the internal server.

Getting Started with HTTPS Inspection

This section gives an example of how to configure a Security Gateway to inspect outbound and inbound HTTPS traffic.

Workflow Overview

Enabling HTTPS Inspection on the Security Gateway

You must configure HTTPS Inspection on each Security Gateway separately.

To enable HTTPS Inspection on a Security Gateway:

Working with Outbound CA Certificate

The first time you enable HTTPS Inspection on one of the Security Gateways, you must create an outbound CA certificate for HTTPS Inspection or import a CA certificate already deployed in your organization. This outbound certificate is used by all Security Gateways managed on the Security Management Server Dedicated Check Point server that runs Check Point software to manage the objects and policies in a Check Point environment within a single management Domain. Synonym: Single-Domain Security Management Server..

Creating an Outbound CA Certificate

The outbound CA certificate is saved with a CER file extension and uses a password to encrypt the private key of the file. The Security Gateways use this password to sign certificates for the sites accessed. You must keep the password because it is also used by other Security Management Servers that import the CA certificate to decrypt the file.

After you create an outbound CA certificate, you must export it so it can be distributed to clients. If you do not deploy the generated outbound CA certificate on clients, users receive TLS error messages in their browsers when connecting to HTTPS sites. You can configure a troubleshooting option that logs such connections.

After you create the outbound CA certificate, a certificate object named Outbound Certificate is created. Use this object in rules that inspect outbound HTTPS traffic in the HTTPS Inspection Rule Base.

Importing an Outbound CA Certificate

You can import a CA certificate that is already deployed in your organization or import a CA certificate created on one Security Management Server Check Point Single-Domain Security Management Server or a Multi-Domain Security Management Server. to another Security Management Server.

For each Security Management Server that has Security Gateways enabled with HTTPS Inspection, you must:

• Import the CA certificate.

• Enter the password the Security Management Server uses to decrypt the CA certificate file and sign the certificates for users. Use this password only when you import the certificate to a new Security Management Server.

Exporting a Certificate from the Security Management Server

If you use more than one Security Management Server in your organization, you must first export the CA certificate with the export_https_cert CLI command from the Security Management Server on which it was created before you can import it to other Security Management Servers.

Command syntax

export_https_cert -help

export_https_cert {[-local] | [-s server]} [-f <certificate file name in the FWDIR/tmp/ directory>]

To export the CA certificate

On the Security Management Server, run this command:

$FWDIR/bin/export_https_cert -local -f <certificate file name in the FWDIR/tmp/ directory>

Example:

$FWDIR/bin/export_https_cert -local -f mycompany.cer

Deploying the Generated CA

To prevent users from getting warnings about the generated CA certificates that HTTPS Inspection uses, install the generated CA certificate used by HTTPS Inspection as a trusted CA. You can distribute the CA with different distribution mechanisms such as Windows GPO. This adds the generated CA to the trusted root certificates repository on client computers.

When users run standard updates, the generated CA is in the CA list and they do not receive browser certificate warnings.

To distribute a certificate with a GPO

Step	Instructions
1	From the HTTPS Inspection window of the Security Gateway, click Export certificate.
2	Save the CA certificate file.
3	Use the Group Policy Management Console to add the certificate to the Trusted Root Certification Authorities certificate store (see Deploying Certificates using Group Policy).
4	Push the Policy to the client computers in the organization. Note - Make sure that the CA certificate is pushed to the client computer organizational unit.
5	Test the distribution by browsing to an HTTPS site from one of the clients. Also, make sure the CA certificate shows the name you entered for the CA certificate that you created in the Issued by field.

Deploying Certificates using Group Policy

You can use this procedure to deploy a certificate to multiple client machines with Active Directory Domain Services and a Group Policy Object (GPO). A GPO can contain multiple configuration options, and is applied to all computers in the scope of the GPO.

Membership in the local Administrators group, or equivalent, is necessary to complete this procedure.

To deploy a certificate using Group Policy

Step	Instructions
1	On the Microsoft Windows Server, open the Group Policy Management Console.
2	Find an existing GPO or create a new GPO to contain the certificate settings. Make sure the GPO is associated with the domain, site, or organization unit whose users you want affected by the policy.
3	Right-click the GPO and select Edit. The Group Policy Management Editor opens and shows the contents of the policy object.
4	Open Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Publishers.
5	Click Action > Import.
6	Do the instructions in the Certificate Import Wizard to find and import the certificate you exported from SmartConsole.
7	In the navigation pane, click Trusted Root Certification Authorities and repeat steps 5-6 to install a copy of the certificate to that store.

Configuring Inbound HTTPS Inspection

By design, the Security Gateway / Security Cluster Two or more Security Gateways that work together in a redundant configuration - High Availability, or Load Sharing. is intentionally configured not to perform HTTPS Inspection on traffic directed towards it. To change this behavior, follow sk114574.

Assigning a Server Certificate for Inbound HTTPS Inspection

Add the server certificates to the Security Gateway. This creates a server certificate object.

When a client from outside the organization initiates an HTTPS connection to an internal server, the Security Gateway intercepts the traffic. The Security Gateway inspects the inbound traffic and creates a new HTTPS connection from the gateway to the internal server. To allow HTTPS Inspection, the Security Gateway must use the original server certificate and private key. The Security Gateway uses this certificate and the private key for TLS connections to the internal servers.

After you import a server certificate (with a CER file extension) to the Security Gateway, add the object to the HTTPS Inspection Policy.

Do this procedure for all servers that receive connection requests from clients outside of the organization.

HTTPS Inspection Policy

The HTTPS Inspection rules define how the Security Gateways inspect HTTPS traffic.

The HTTPS Inspection rules can use the URL Filtering Check Point Software Blade on a Security Gateway that allows granular control over which web sites can be accessed by a given group of users, computers or networks. Acronym: URLF. categories to identify traffic for different websites and applications. For example, to protect the privacy of your users, you can use a rule to ignore HTTPS traffic to banks and financial institutions.

For HTTPS Inspection to be enforced on a gateway on a specific blade, you must:

1. Enable HTTPS Inspection on the gateway.

2. Create a rule in the HTTPS Inspection policy with the required blade.

3. Enable the required blade on the gateway.

These are the Software Blades that support HTTPS Inspection:

• Access Control:

  • Application Control Check Point Software Blade on a Security Gateway that allows granular control over specific web-enabled applications by using deep packet inspection. Acronym: APPI.

  • URL Filtering

  • Content Awareness Check Point Software Blade on a Security Gateway that provides data visibility and enforcement. See sk119715. Acronym: CTNT.

• Threat Prevention:

  • IPS Check Point Software Blade on a Security Gateway that inspects and analyzes packets and data for numerous types of risks (Intrusion Prevention System).

  • Anti-Virus Check Point Software Blade on a Security Gateway that uses real-time virus signatures and anomaly-based protections from ThreatCloud to detect and block malware at the Security Gateway before users are affected. Acronym: AV.

  • Anti-Bot Check Point Software Blade on a Security Gateway that blocks botnet behavior and communication to Command and Control (C&C) centers. Acronyms: AB, ABOT.

  • Threat Emulation Check Point Software Blade on a Security Gateway that monitors the behavior of files in a sandbox to determine whether or not they are malicious. Acronym: TE.

• Data Loss Prevention Check Point Software Blade on a Security Gateway that detects and prevents the unauthorized transmission of confidential information outside the organization. Acronym: DLP.

Configuring HTTPS Inspection Policy

Create different HTTPS Inspection rules for outbound and inbound traffic.

The outbound rules use the certificate that was generated for the Security Gateway.

The inbound rules use a different certificate for each internal server.

You can also create bypass rules for traffic that is sensitive and should not be inspected. Make sure that the bypass rules are at the top of the HTTPS Inspection Rule Base.

After you create the rules, install the Access Control Policy.

Bypassing HTTPS Inspection for Software Update Services

Check Point dynamically updates a list of approved domain names of services from which content is always allowed. This option makes sure that Check Point updates or other 3rd party software updates are not blocked. For example, updates from Microsoft, Java, and Adobe.

To bypass HTTPS Inspection for software updates

Step	Instructions
1	In SmartConsole, go to Security Policies > HTTPS Inspection> HTTPS Tools > Additional Settings > Open HTTPS Inspection Policy in SmartDashboard.
2	In SmartDashboard, click the HTTPS Inspection tab.
3	Click HTTPS Validation.
4	Go to Whitelisting and select Bypass HTTPS Inspection of traffic to well-known software update services (list is dynamically updated). This option is selected by default.
5	Click list to see the list of approved domain names.

Managing Certificates by Gateway

The Gateways pane in the HTTPS Inspection tab in SmartDashboard lists the gateways with HTTPS Inspection enabled.

In the CA Certificate section, in the lower part of the Gateways pane, you can Renew the certificate validity date range if necessary and Export it for distribution to the organization client machines.

If the Security Management Server which manages the selected Security Gateway does not have a generated CA certificate installed on it, you can add it with Import certificate from file.

• You can import a CA certificate already deployed in your organization.

• You can import a CA certificate from another Security Management Server. Before you can import it, you must first export it from the Security Management Server on which it was created (see HTTPS Inspection).

Adding Trusted CAs for Outbound HTTPS Inspection

When a client initiates an HTTPS connection to a website server, the Security Gateway intercepts the connection. The Security Gateway inspects the traffic and creates a new HTTPS connection from the Security Gateway to the designated server.

When the Security Gateway establishes a secure connection (a TLS tunnel) to the designated website, it must validate the site server certificate.

HTTPS Inspection comes with a preconfigured list of trusted CAs. This list is updated by Check Point when necessary and is automatically downloaded to the Security Gateway. After you install the update, make sure to install the policy. You can select to disable the automatic update option and manually update the Trusted CA list.

If the Security Gateway receives a non-trusted server certificate from a site, by default the user gets a self-signed certificate and not the generated certificate. A page notifies the user that there is a problem with the website security certificate, but lets the user continue to the website.

You can change the default setting to block untrusted server certificates.

Saving a CA Certificate

You can save a selected certificate in the trusted CAs list to the local file system.

To export a CA certificate

Step	Instructions
1	In SmartDashboard, go to the HTTPS Inspection tab > Trusted CAs.
2	Click Actions > Export to file.
3	Browse to a location, enter a file name and click Save. A *.cer file is created.

HTTPS Validation

In the HTTPS Validation page of SmartDashboard you can set options for

• Fail mode

• HTTPS site categorization mode

• Server validation

• Certificate blacklisting

• Whitelisting

• Troubleshooting

To learn more about these options, see the Help. Click the ? symbol in the HTTPS Validation page.

Showing HTTPS Inspection Logs

The predefined log query for HTTPS Inspection shows all HTTPS traffic that matched the HTTPS Inspection policy, and was configured to be logged.

To see HTTPS Inspection Logs

Step	Instructions
1	In the SmartConsole Logs & Monitor view, go to the Logs tab, and click Queries.
2	Select the HTTPS Inspection query.

The Logs tab includes an HTTP Inspection Action field. The field value can be inspect or bypass. If HTTPS Inspection was not done on the traffic, this field does not show in the log.

SNI support for Site Categorization

Starting from R80.30, a new functionality allows the categorization of HTTPS sites before the HTTPS Inspection begins, and prevents connectivity failure if the inspection does not succeed.

SNI is an extension to the TLS protocol, which indicates the hostname at the start of the TLS handshaking process.

The categorization is performed by examining the SNI field in the client hello message at the beginning of the TLS handshaking process. To make sure that you reached the right site, the SNI is verified against the Subject Alternative Name of the host, which appears in the certificate.

After the identity of the host is known and verified, the site is categorized, and it is determined whether the connection should be inspected or not.

SNI support is enabled by default.

HTTPS Inspection on Non-Standard Ports

Applications that use HTTP normally send the HTTP traffic on TCP port 80. Some applications send HTTP traffic on other ports also. You can configure some Software Blades to only inspect HTTP traffic on port 80, or to also inspect HTTP traffic on non-standard ports.

The security policies inspect all HTTP traffic, even if it is sent using nonstandard ports. This option is selected by default. You can configure this option in the Manage & Settings view > Blades > Threat Prevention > Advanced Settings > General > HTTPS Inspection.

Inspection of TLS v1.3 Traffic

From R81, the Check Point Security Gateway can inspect traffic that relies on Transport Layer Security (TLS) v1.3 (see RFC 8446).

From R81.10, this feature is enabled by default for Security Gateways (and Cluster Members) that use the User-Space Firewall Mode (USFW)).

For the list of supported platforms, see sk167052.

The HTTPS Inspection feature decrypts traffic for better protection against advanced threats, bots, and other malware.