Best security practices for Trusted TLS Intermediary

by John Neystadt on July 25, 2018

According to Google over 75% of public websites are accessed over encrypted connections using HTTPS, with the use of HTTP diminishing. As expected, the bad actors are following the crowds, and using HTTPS to hide their activities.

So how can security solutions such as ETP Threat Protector detect and block threats within HTTPS traffic? In short, the answer is a best practice implementation of a Trusted TLS Intermediary, enabling enterprises to proxy and decrypt TLS traffic for the purposes of detecting and blocking threats.

Trusted TLS Intermediary Approach

A basic approach for doing this is splitting an end-to-end encrypted Client-to-Origin TLS connection into two separate TLS connections: 1) Client-to-Proxy and 2) Proxy-to-Origin. Since Proxy does not have access to Origin’s TLS certificate private keys, it must present its own certificate, with the Subject field matching Origin’s certificate.

How would an organization’s computers know that this is not a man-in-the-middle (MITM) attack by a bad actor? Enterprises configure organizational computers to trust a special Enterprise Certificate Authority, and so that HTTP Proxy such as ETP Proxy can use that CA as root of the certificate chain for generating certificates representing origin servers. This way client computers will accept HTTP Proxy as a Trusted Intermediary, while blocking malicious man-in-the-middle attack attempts.

Sponsorships Available

Trusted TLS Intermediary Threat Model

Much research has been conducted into threats of TLS inspection with middle boxes. TLS inspection requires a robust security architecture and rigorous security management, so that the confidentiality, integrity and authenticity characteristics provided by TLS/HTTPS are preserved.

Enterprise IT can shift many of the operational risks to Akamai by relying on the Akamai Cloud as an operated Trusted TLS Intermediary Service, all while being confident that best security practices around certificate management and TLS handling are implemented.

	Risk	Required Mitigation
1.	Attacker stealing CA private keys	Enterprises that already have their own Root CA deployed on its desktops should keep working with it, delegating only an Intermediary MITM CA to Akamai ETP, avoiding additional configuration of their enterprise desktops Restrict access to Root CA private keys to a handful of IT personnel, guard CA private keys with hardware key storage (such as HSM) Restrict the lifetime of Intermediary MITM CA certificate to 2 years or less, and implement timely certificate rotation procedure Akamai stores the long-lived Intermediary MITM CA certificate keys on a special secure KMI network, access to which is severely restricted
2.	Attacker compromising HTTP Proxy, can generate MITM certificates for popular web sites and use them to access on employee traffic	Akamai generates another (3rd) subsidiary CA certificate from MITM CA. Only that CA certificate and keys are deployed to the Akamai Edge Proxy network. This certificate and its keys are automatically rotated every month.
3.	Attacker compromising HTTP Proxy, can steal already generated MITM certificates and use it outside of HTTP Proxy	Actual origin MITM certificate is assigned a very short validity of 6 hours, and automatically rotated after that
4.	Man-in-the-middle attack from Internet on Proxy to Origin connection	On the TLS connection between ETP Proxy and the origin, ETP proxy performs origin certificate validation, including certificate Subject matching to the origin domain, expiration checks and certificate chain signing validation to correspond to Trusted Public CA Root Certificates ETP Proxy verifies that origin certificate is not revoked according to TLS specification, using OCSP stapling, OCSP and CRL fields in the certificate ETP Proxy rejects connections with origins and clients if they demand known vulnerable TLS versions and cipher suites ETP Proxy returns to the client only TLS version and TLS cipher suites that origin has presented, so that client can reject the TLS connection, if cipher suite list does not satisfy client security policy
5.	Enterprise IT watching employee personal browsing done from enterprise desktops	It is a responsibility of the IT organization to protect the network and data of the Enterprise, and monitoring it for threats is required. Apply ETP TLS MITM selectively on traffic you consider a security threat, and skip TLS MITM for domains, which are not considered a risk. Web browsing activity within allowed organization policy cannot be accessed by Administrator. ETP keeps all traffic logs only for 30 days, restricting period over which the traffic can be seen.

With all these mitigations in place, performing inspection of suspicious TLS traffic, is the right approach to protect the enterprise network from threats.

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by John Neystadt. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/0vhKFW8ua2M/best-security-practices-for-trusted-tls-intermediary.html