HTTPS Internet traffic uses the SSL (Secure Sockets Layer) protocol and is encrypted to give data privacy and integrity. However, HTTPS traffic has a possible security risk and can hide illegal user activity and malicious traffic. Security Gateways cannot inspect HTTPS traffic because it is encrypted. You can enable the HTTPS Inspection feature to let the Security Gateways create new SSL connections with the external site or server. The Security Gateways are then able to decrypt and inspect HTTPS traffic that uses the new SSL connections.
There are two types of HTTPS Inspection:
A Security Gateway uses certificates and becomes an intermediary between the client computer and the secure web site. All data is kept private in HTTPS Inspection logs. Only administrators with HTTPS Inspection permissions can see all the fields in such a log.
Outbound connections are HTTPS connections that arrive from an internal client and connect to the Internet. The Security Gateway compares the HTTPS request to the rules in the HTTPS Inspection Rule Base. If the request does not match any rule, the packet is not inspected and the connection is allowed.
If the request matches an HTTPS Inspection rule, the Security Gateway validates the certificate from the server (on the Internet). The Security Gateway validates the certificate using the Online Certificate Status Protocol (OCSP) standard. OCSP is faster and uses much less memory than CRL Validation, which is used for certificate validation in releases lower than R80.10. For a new HTTPS connection to the server, the Security Gateway creates and uses a new certificate. There are two HTTPS connections, one to the internal client and one to the external server. It can then decrypt and inspect the packets according to the security policy. The packets are encrypted again and sent to the destination.
|
|
|
|
Connection is not inspected |
|
|
|
|
|
|
No |
|
|
HTTPS request |
Firewall inspects request |
Matches a rule? |
Yes |
Firewall validates certificate |
||
|
|
|
|
|
|
|
|
|
Firewall inspects unencrypted connection and then encrypts it |
Decrypts the connection |
Creates new certificate for client and server |
Inbound connections are HTTPS connections that arrive from an external client and connect to a server in the DMZ or the internal network. The Security Gateway compares the HTTPS request to the rules in the HTTPS Inspection Rule Base. If the request does not match any rule, the packet is not inspected and the connection is allowed.
If the request matches an HTTPS Inspection rule, the Security Gateway uses the certificate for the internal server to create an HTTPS connection with the external client. The Security Gateway creates a new HTTPS connection with the internal server. Since the Security Gateway has a secure connection with the external client, it can decrypt the HTTPS traffic. The decrypted traffic is inspected according to the security policy.
|
|
|
|
Connection is not inspected |
|
|
|
|
|
|
No |
|
|
HTTPS request |
Firewall inspects request |
Matches a rule? |
Yes |
Uses server certificate and connects to the client |
||
|
|
|
|
|
|
|
|
|
Firewall inspects unencrypted connection |
Decrypts the connection |
Creates a new connection to server |
This section gives an example of how to configure a Gateway to inspect outbound and inbound HTTPS traffic.
Workflow overview
You must enable HTTPS Inspection on each Security Gateway.
To enable HTTPS Inspection on a Security Gateway:
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.
The outbound CA certificate is saved with a P12 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 will receive SSL 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.
To create an outbound CA certificate:
The Gateway Properties window opens.
The Create window opens.
You can import a CA certificate that is already deployed in your organization or import a CA certificate created on one Security Management Server to use on another Security Management Server.
Best Practice - Use private CA Certificates.
For each Security Management Server that has Security Gateways enabled with HTTPS Inspection, you must:
To import a CA certificate:
The Gateway Properties window opens.
The Import Outbound Certificate window opens.
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 [-local] | [-s server] [-f certificate file name under FWDIR/tmp][-help]
To export the CA certificate:
On the Security Management Server, run this command:
$FWDIR/bin/export_https_cert -local -f [certificate file name under FWDIR/tmp]
Example
$FWDIR/bin/export_https_cert -local -f mycompany.p12
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 will be in the CA list and they will not receive browser certificate warnings.
To distribute a certificate with a GPO:
Note - Make sure that the CA certificate is pushed to the client computer organizational unit.
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:
The Group Policy Management Editor opens and shows the contents of the policy object.
Configure the Security Gateway for inbound HTTPS Inspection.
To enable inbound HTTPS traffic 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 SSL connections to the internal servers.
After you import a server certificate (with a P12 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.
To add a server certificate for inbound HTTPS Inspection:
SmartConsole opens.
The Import Inbound Certificate window opens.
The Successful Import window opens the first time you import a server certificate. It shows you where to add the object in the HTTPS Inspection Rule Base. Click Don't show this again if you do not want to see the window each time you import a server certificate and Close.
The HTTPS Inspection rules define how the Security Gateways inspect HTTPS traffic. The HTTPS Inspection rules can use the URL Filtering 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.
The HTTPS Inspection rules are applied to all the Software Blades that have HTTPS Inspection enabled. These are the Software Blades that support HTTPS Inspection:
To open the HTTP Inspection Policy
HTTPS Inspection rules in SmartConsole
These are the fields that manage the rules for the HTTPS Inspection security policy.
Field |
Description |
---|---|
No. |
Rule number in the HTTPS Inspection Rule Base. |
Name |
Name that the system administrator gives this rule. |
Source |
Network object that defines where the traffic starts. |
Destination |
Network object that defines the destination of the traffic. |
Services |
The network services that are inspected or bypassed. By default, the services |
Site Category |
Categories for applications or web sites that are inspected or bypassed. |
Action |
Action that is done when HTTPS traffic matches the rule. The traffic is inspected or ignored (Bypass). |
Track |
Tracking and logging action that is done when traffic matches the rule. |
Install On |
Network objects that will get the HTTPS Inspection rule. You can only select Security Gateways that have HTTPS Inspection enabled. |
Certificate |
The certificate that is used for this rule.
|
Comment |
An optional field that lets you summarize the rule. |
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 is not inspected. Make sure that the bypass rules are at the top of the HTTPS Inspection Rule Base.
After creating the rules, install the Access Control Policy.
Sample HTTPS Inspection Rule Base
This table shows a sample HTTPS Inspection Rule Base for a typical policy. (The Track and Install On columns are not shown. Track is set to None and Install On is set to Any.)
No |
Name |
Source |
Destination |
Services |
Site Category |
Action |
Blade |
Certificate |
---|---|---|---|---|---|---|---|---|
1 |
Inbound traffic |
Any |
WebCalendar Server |
HTTPS |
Any |
Inspect |
Any |
WebCalendarServer CA |
2 |
Financial sites |
Any |
Internet |
HTTPS HTTP_HTTPS_proxy |
Financial Services |
Bypass |
Any |
Outbound CA |
3 |
Outbound traffic |
Any |
Internet |
HTTPS HTTP_HTTPS_proxy |
Any |
Inspect |
Any |
Outbound CA |
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:
The Gateways pane lists the gateways with HTTPS Inspection enabled. Select a gateway and click Edit to edit the gateway properties.
In the CA Certificate section, 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.
When a client initiates an HTTPS connection to a web site 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 (an SSL tunnel) to the designated web site, 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. The system is configured by default to notify you when a Trusted CA update file is ready for installation. The notification in SmartConsole shows as a pop-up notification or in the Trusted CAs window in the Automatic Updates section. 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.
You can save a selected certificate in the trusted CAs list to the local file system.
To export a CA certificate:
A CER file is created.
In the HTTPS Validation page of SmartConsole you can set options for
To learn more about these options, see the Help. Click ? in the HTTPS Validation page.
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:
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.
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.
When selected, the Threat Prevention policy inspects 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.