Last month, we presented a webcast on Visibility into Encrypted Traffic. In the webcast, we explain how TLS inspection and SSL/TLS DPI work. In this article, I’d like to go over the technical aspects of how you can gain visibility into encrypted traffic with TLS DPI. I will also explain an alternative to TLS inspection, should it not be a viable option in your organization.

Encrypted TLS traffic is critical to conduct business across the Internet. Such encryption, however, can be used to conceal attacks. To prevent these attacks, organizations need a way to decrypt the traffic. One method, as mentioned above, is TLS inspection.

How TLS Inspection Works

Browser Trust

First, let me explain browser trust. When you connect to a website over HTTPS, you are requesting from the server, via the TLS handshake, the server’s certificate. The web server needs a way to prove that it’s the rightful owner of the site; it does so with a file called the private key. This key is cryptographically paired with the certificate.  Without the private key, nobody can forge its certificate, thereby preventing someone from impersonating the site online. Only the web server will have access to this key.

This certificate is issued by a certificate authority (CA) that is trusted by the browser because it is listed in the browser’s trusted store. In Google Chrome and Internet Explorer, the trusted store is managed by Microsoft. Firefox has its own trusted store maintained by Mozilla.

At the time of writing, our website uses a certificate signed by the DigiCert Global Root CA, which is stored in the trusted root store.

trusted-certificate-store

TLS Inspection

When you enable the TLS inspection/SSL DPI functionality on your gateway, you create your own CA that will be used to sign certificates. This CA is installed on your clients’ machines so that it is trusted equally to other CA certificates (e.g. DigiCert Global Root CA). When you connect to an encrypted site via the gateway, the following takes place:

  • The browser sends the request for the certificate to the web server.
  • This time, however, instead of letting the request through, the gateway holds the request and sends its own request to the web server, pretending to be the browser.
  • The web server then sends the certificate to the gateway.
  • The gateway, like the browser, validates the web server’s certificate (the gateway also has a trusted store of certificates to validate the certificate from the web server; this validation is a vital part of the process as it preserves the trust validations normally done by the browser (we wouldn’t want to allow revoked or invalidated certificates to get through, would we?)).
  • Now that the gateway and web server connection is established, the gateway creates a certificate that is very similar to the one issued to the web server.
    • Like the web server’s certificate, the gateway certificate has its own private key.
  • The gateway signs the copied certificate using the gateway’s CA certificate installed on the clients’ machines.
  • Finally, the gateway completes the TLS session with the browser, pretending to be the web server by using the newly created certificate.
tls_certificate_gateway

As we can see in the image above, the certificate generated from our SonicWALL firewall with SSL DPI enabled is signed by SonicWALL, Inc., not DigiCert.

For additional information on how TLS handshakes work and how they are encrypted, I recommend this video below.

Alternatives to TLS Inspection

Because TLS inspection requires additional resources from the gateway, this is not a viable option for all organizations, especially those that were not planning for the additional load when they provisioned their gateway. As an alternative, though, you can use FlowPro Defender to gain insight about which sites are being visited. FlowPro Defender does this by correlating DNS queries and NetFlow details.

FQDN Report

As you can see in this report, we are given the Fully Qualified Domain Name (FQDN) for the site that a user visited instead of seeing only encrypted or CDN (e.g. Amazon AWS and Akamai) traffic URLs.

Contact us with any questions you have about FlowPro Defender and how it can help you gain visibility into encrypted traffic contact support.

Justin

Justin Jett is Director of Audit and Compliance at Plixer with roles ranging from system administration of web services to technical product marketing for Plixer’s incident response system, Scrutinizer. Jett, a graduate of the University of Maine at Farmington, is an avid learner of all things security, with a particular interest in TLS and DNS attacks.

Related