SSL_Inspection

CISSP   SSL Inspection

Analysis of httpS Encryption with SSL/TSL Inspection

HTTPS and SSL 
SSL based HTTPS is widely  implement to secure communication. However, SSL can hide illegal user activity and malicious traffic.  The SSL protocol is widely implemented in public resources that include: banking, web mail, user forums,and corporate web resources. SSL secures communication between internet browser clients and web servers. It also supplies data privacy and integrity by encrypting the traffic, based on standard encryption ciphers.

However, SSL has a potential security gap. It can hide illegal user activity and malicious traffic from the content inspection of Security Gateways.  One example of a threat is when an employee uses HTTPS (SSL based) to connect from the corporate network to internet web servers. Security Gateways without HTTPS Inspection are unaware of the content passed through the SSL encrypted tunnel. This makes the company vulnerable to security attacks and sensitive data leakage

For HTTPS traffic inspection encrypted data is:
Intercepted by the Security Gateway and decrypted
Inspected by the blades set in the policy
Encrypted again and sent to the designated web server

You can enable HTTPS traffic inspection on Security Gateways to prevent security risks related to the
Secure Sockets Layer (SSL) protocol.
When a client computer initiates an HTTPS connection to a secure site, the Security Gateway:

1.  Intercepts the request.
2. Establishes a secure connection (an SSL tunnel) to the requested website and validates the site's server certificate
3. Creates a new SSL certificate for the communication between the Security Gateway and the client, sends the client the new certificate and establishes a different SSL tunnel with it
4. Using the two tunnels:
1. It decrypts the encrypted data from the client.
2. Inspects the clear text content for all blades set in the policy.

Encrypts the data again to keep client privacy as the data travels to the destination web server
resource.

The signature
Check Point IPS Update Service produces new protections to protect against emerging exploits and vulnerabilities to help security administrators stay continuously ahead of today's constantly evolving threat landscape.


Here are some references to HTTPS Inspection. Plus sk108202 has a whole section on additional references. We made significate enhancements in R77.30 with HTTPS Inspection.
Application Control and URL Filtering R77 Versions Administration Guide – (how to configure HTTPS Inspection)

TRUST / SSL handshake Client/webserver   TRUSTED CA Store

Impersonate  without private.key and Certificate

Gateway certificate MUST be ADDED to the browser TRUSTED STORE

How SSL is use by browser

the cllient goes to  httpS://www.facebook.com

The browser is using httpS  the S denotes the http session is encrypted with SSL

The first function of SSL is to establish TRUST with the site.

The browser TRUST a webserver if the server has a digital certificate that was issued by a trusted Certificate Authority =CA.  That is vetting the site's identity

The SSL handshake starts off with the webserver sending its SSL Certificate to the client browser

Facebook webserver needs a way to prove it is the rightful owner of the certificate.

Facebook has a file call the private.key with is cryptographically prepared with its certificate

Without the possession of facebook's the private.key no one can forge a certificate to impersonate a its sight on the web.  This is a key part of SSL

Facebook certificate is sign by a CA named Verisign

Our browser searches for Versign Certificate in its store of TRUSTED CA certificates.

In windows, the list of TRUSTED CAs is maintained by Microsoft

In our example the Versign certificate is found in the trusted store

so the browser decided to TRUST Facebook Certificate.

Now that the SSL cryptographically validation is done and the browser trust the website

Browsing commencing using SSL crypted communication.

Let’s visit Facebook again but now we are turning on Checkpoint SSL inspection

Do this from the https Inspection page on the SmartDashbpard

The first step for SSL inspection is to create a CA certificate to be used by the gateway for signing

We provide a certificate Name, validation date and a password that will protect the private.key

We then enable HTTPS inspection

Now let’s visit https//wwww.facebook.com again and see what happens this time

The gateway sees the browser's SSL request

Rather than letting the request thru,  (Hold Request), and initiates its own SSL Session with Facebook pretending to be our browser like the browser, the gateway has its own TRUSTED CA Store which is used to Validate Facebook certificate.

This validate is critical in order to preserve the trust validation that is normally carried out by the browser.

Once the connection between the gateway and Facebook is established, the gateway creates an SSL certificate which is similar to that of Facebook

This certificate has its own private key associate with it

The gateway signs the copied certificate with its CA certificate which was created for the gateway.

Now the gateway completed the SSL session with our browser pretending to be Facebook and using the now just created certificate

But just wait, the certificate the gateway generated for Facebook was not signed by the CA that the browser TRUST.

It was signed by the Certificate were created a moment ago.  The browser WARNS the browser that the certificate is NOT valid.  One more KEY step must happen before the gateway can perform SSL inspection without generate a warming in our browser.

That is our gateway certificate MUST be ADDED to the browser TRUSTED STORE

to accomplish this, we export the gateway CA store file (that’s the second step we omitted before)

The imported it manually to the PC Browser trusted store

You can automatically distribute the Gateway CA by using Microsoft Group policy object in Microsoft Active Directory (AD)

From this point on, the browser TRUST Certificates generated by the gateway and it will trust the one generated for Facebook

At this point the gateway has established SSL connection between FACEBOOK and our browser acting BRIDGE between the two

This way, the gateway can inspect the content of the SSL Traffic

EXAMPLE

DLP

USE HTTPS Inspection Policy to exclude traffic for on-line banking and health sight to prevent

HTTPS Inspection

You can enable HTTPS traffic inspection on Security Gateways to inspect traffic that is encrypted by the Secure Sockets Layer (SSL) protocol. SSL secures communication between internet browser clients and web servers. It supplies data privacy and integrity by encrypting the traffic, based on standard encryption ciphers.

However, SSL has a potential security gap. It can hide illegal user activity and malicious traffic from the content inspection of Security Gateways. One example of a threat is when an employee uses HTTPS (SSL based) to connect from the corporate network to internet web servers. Security Gateways without HTTPS Inspection are unaware of the content passed through the SSL encrypted tunnel. This makes the company vulnerable to security attacks and sensitive data leakage.

The SSL protocol is widely implemented in public resources that include: banking, web mail, user forums, and corporate web resources.

There are two types of HTTPS inspection:

• Inbound HTTPS inspection - To protect internal servers from malicious requests originating from the internet or an external network.
• Outbound HTTPS inspection - To protect an organization from malicious traffic being sent by an internal client to a destination outside of the organization.

The Security Gateway acts as an intermediary between the client computer and the secure web site. The Security Gateway behaves as the client with the server and as the server with the client using certificates.

All data is kept private in HTTPS Inspection logs. This is controlled by administrator permissions. Only administrators with HTTPS Inspection permissions can see all the fields in a log. Without these permissions, some data is hidden.

How it Operates

In outbound HTTPS inspection, when a client in the organization initiates an HTTPS connection to a secure site, the Security Gateway:

1. Intercepts the request.
2. Establishes a secure connection to the requested web site and validates the site server certificate.
3. Creates a new SSL certificate for the communication between the Security Gateway and the client, sends the client the new certificate and continues the SSL negotiation with it.
4. Using the two SSL connections:
   1. It decrypts the encrypted data from the client.
   2. Inspects the clear text content for all blades set in the Policy.
   3. Encrypts the data again to keep client privacy as the data travels to the destination web server resource.

In inbound HTTPS inspection, when a client outside of the organization initiates an HTTPS connection to a server behind the organization's gateway, the Security Gateway:

1. Intercepts the request.
2. Uses the server's original certificate and private key to initiate an SSL connection with the client.
3. Creates and establishes a new SSL connection with the web server.
4. Using the two SSL connections:
   1. It decrypts the encrypted data from the client.
   2. Inspects the clear text content for all blades set in the policy.
   3. Encrypts the data again to keep client privacy as the data travels to the destination server behind the gateway.

Configuring Outbound HTTPS Inspection

To enable outbound HTTPS traffic inspection, you must do these steps:

• Set the Security Gateway for HTTPS Inspection.
• Generate a CA certificate on the Security Management Server or import a CA certificate already deployed in your organization.
  • If you created a CA certificate, you must deploy it in the Trusted Root Certification Authorities Certificate Store on the client computers. This lets the client computers trust all certificates signed by this certificate.
• Generate an HTTPS inspection policy by defining relevant rules in the HTTPS inspection Rule Base.
• Configure the conditions for dropping traffic from a web site server.
  When required, you can update the trusted CA list in the Security Gateway.

Enabling HTTPS Inspection

You must enable HTTPS inspection on each Security Gateway. From Security Gateway > HTTPS Inspection > Step 3 > Select Enable HTTPS Inspection.

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.

Creating an Outbound CA Certificate

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 as it 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 in rules that inspect outbound HTTPS traffic in the HTTPS inspection Rule Base.

To create an outbound CA certificate:

1. In SmartDashboard, right-click the Security Gateway object and select Edit.
   The Gateway Properties window opens.
2. In the navigation tree, select HTTPS Inspection.
3. In the HTTPS Inspection page, click Create.
4. Enter the necessary information:
   • Issued by (DN) - Enter the domain name of your organization.
   • Private key password - Enter the password that is used to encrypt the private key of the CA certificate.
   • Retype private key password - Retype the password.
   • Valid from - Select the date range for which the CA certificate is valid.
5. Click OK.
6. Export and deploy the CA certificate.

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

Usage:

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:
  $FWDIR/bin/export_https_cert -local -f [certificate file name under FWDIR/tmp]
  For example:
  $FWDIR/bin/export_https_cert -local -f mycompany.p12

HTTS Inspection Best Practice
Solution Title: Best Practices - HTTPS Inspection
Solution ID: sk108202

HTTPS Inspection FAQ
Solution Title: HTTPS Inspection FAQ
Solution ID: sk65123

HTTPS Inspection

https://www.youtube.com/watch?v=1lJBBRsc03A