In the first blog post I covered why HTTPS web traffic has grown to unprecedented levels, provided a TLS primer and looked at the basic concept of intercepting and inspecting HTTPS web traffic with Man-In-The-Middle techniques (MITM). In the second part, I will dive a bit deeper into how the TLS MITM capability has been implemented in Akamai’s Enterprise Threat Protector (ETP) service.
ETP TLS MITM Proxy Architecture
The basic concept of the ETP proxy is shown in the following diagram.
The ETP Proxy is a “trusted intermediary” that is able to decrypt, inspect, and re-encrypt all TLS traffic from managed devices. This gives ETP visibility into TLS encrypted traffic and allows it to protect an enterprise from threats, while preserving confidentiality and integrity of traffic to origin web sites.
ETP Proxy uses a MITM Certificate Authority (CA) certificate to generate and sign MITM origin certificates for HTTPS web sites that go through it. For enterprise client computers to accept and trust these certificates, the MITM CA must be deployed on all enterprise computers.
ETP Proxy and TLS Certificates
To show how the Proxy in ETP operates and specifically how it handles TLS certificates, let’s first look at how a normal TLS web request operates.
As can be seen in this example, the user has made a request to access https://www.facebook.com. As part of the handshake process between the client and the web server, the web server returns to the client an x.509 certificate to establish trust with the client – see the details of the certificate below.
As can be seen from the certificate, this was issued and signed by DigiCert Inc., a Certificate Authority or CA. The DigiCert High Assurance EV Root CA is a trusted System Root that is distributed with browsers.
Now let’s examine what happens when that same request is made and intercepted by the ETP Proxy.
As part of the decryption process, the original certificate sent by the webserver is copied and resigned by Akamai as the Intermediate Root as seen in the following diagram.
The browser will display a security warning message as shown in the following diagram.
While users could simply ignore the security warnings and continue to the site, this is not a good security practice and will inevitably lead to user frustration, as the security warning will be displayed every time users visit a proxied HTTPs website.
Let us now look at how we fix the trust chain problem that causes this browser security warning.
Fixing Browser Security Warnings
There are two approaches to fixing the browser security warnings. These are:
- Signing the Intermediate Certificate Authority with a Private Certificate Authority – this is the preferable method, as it is more secure and simpler to deploy. Use this method if you already have an Enterprise Root CA root certificate deployed on devices
- Signing the Intermediate Certificate Authority with an Akamai Root CA and deploying that on all your devices – use this method if you don’t have your own Private CA root certificate deployed on your devices.
Using an Existing Enterprise Root CA
To use a Private Certificate Authority, you must create a Certificate Signing Request (CSR) for the Intermediate Root. The CSR is created in the Akamai Control Center (portal) and signed by your private CA. Note that the issued certificate must be an Intermediate CA as opposed to a server or other certificate type.
The signed Intermediate Root CA certificate is then uploaded to the Akamai Control Center, which distributes the certificate to the Akamai Intelligent Platform’s proxy machines.
The Root Certificate that is used to sign the Intermediate Certificate must be trusted by the device – this is indicated by the blue plus icon in the following figure. See the product documentation for more information.
Using the Akamai CA
Another configuration option in ETP is to use an Akamai-signed certificate. To use the Akamai CA as an intermediate root certificate, you need to download the certificate from the Akamai Control Center (portal) and copy it into the trust store on every device.
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Jim Black. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/hQQir5tN2L0/inspecting-tls-web-traffic---part-2.html