Managing Risk from TLS Inspection

Recently, the National Security Agency (NSA) published a guide to Managing Risk from Transport Layer Security Inspection. The guide is designed to highlight the unique risks introduced into environments by the use of TLS inspection appliances. It also covers a few recommendations on how to secure these devices. There are some additional areas we recommend over and above what the NSA describes.

But first, let’s briefly touch on what these appliances are. TLS inspection devices are designed to decrypt and examine network traffic as it egresses a network to the internet. Specifically, the TLS encrypted traffic is usually associated with Internet website HTTPS communication. However, TLS encryption can be used by both valid and nefarious actors to obscure the information being transmitted.

To function, the appliances need to act as a Man-in-the-middle. Essentially, they need to decrypt the traffic sent, process the information and then open a new TLS session to the actual recipient on the internet. For this to work, the appliance needs to be trusted as a Certificate Authority. The reason is that it creates an ad-hoc certificate that imitates the desired recipient (disney.com or cnn.com for instance). There is an inherent weakness in TLS – a browser doesn’t know WHICH certificate really should be assigned to website. It just looks to see if the certificate it finds comes from a trusted source, and if it is trusted, then the subject identity in the certificate “must” be valid. There are concepts such as Certificate Pinning that can prevent this from occurring, but they are rarely used because of complexity and ongoing management issues.

These appliances, such as Palo Alto, Checkpoint, and Bluecoat all come with the ability to self-sign a certificate. But the use of self-signed certificates provides no management or control over the identity and key. So the appliances also support the use of a certificate from an internal trusted PKI. However, once these devices are given a subordinate CA certificate, they are trusted as much as any other CA in the environment. This is particularly concerning because of the placement on the network perimeter or possible even in the DMZ itself. This the crux of the NSA article on managing the risk.

This risk is especially important to consider if you have gone through the process of implementing controls for your CA such as Hardware Security Modules, two-person controls or even implemented a Certificate Policy/Practice Statement. The appliances, often without the ability to use a HSM, will be placing its key into software protection and creating a vulnerability in your environment compared to the key protections implemented on your “real” CAs.

The NSA guideline has some good information, but in practice may be difficult to achieve and lacking in other options.

Ensure the embedded CA is configured to issue only TLS server authentication certificates, as indicated in the value of their “extended key usage” field. Configure TLS clients to trust the external CA so they only trust the certificates the TLSI system issued for TLS server authentication. Issue the embedded CA with a certificate that has name constraints to reinforce limitations of the inspection authorization and prevent impersonation of enterprise services.

NSA – Managing Risk from Transport Layer Security Inspection

So, lets cover a few items would like to assert about this article:

EKU: We entirely agree that these devices should be issued a subordinate CA certificate valid for Server Authentication only. This takes extra effort – either through the use of a Policy CA dedicated to this purpose (our usual recommendation) or through careful use of the certreq -submit -attrib process to ensure the request is issued with only this purpose. It is worth noting all of the appliances create a generic CA CSR which means the issuing CA must enforce this restriction.

External CA: The guideline references “Issue the embedded CA’s signing  certificate from an external CA trusted only for TLS inspection purposes“. It is generally not possible to purchase a certificate from an external CA for a subordinate CA. Commercial CAs don’t typically sell the ability to stand up your own subordinate CA under their PKI. This used to be more common through “Qualified Subordination” programs but has largely been discontinued because of Certificate Transparency requirements. So this means the certificate needs to come from your internal CA. But as highlighted above, the issued certificate should be restricted to Server Authentication only.

Self-signed Certificates: As stated, “Do not use default or self-signed certificates.“ – We agree!

Constraints: One area the guideline misses is that there are some additional controls that can be placed to ensure the appliance risk is managed. One of those is the Path Length constraint in the Basic Constraints (See 4.2.1.9. Basic Constraints) extension. When set to 0, a CA can not issue a subordinate CA. So by ensuring the TLS inspection appliance is unable to issue any other subordinate CAs, the environment can be protected by an adversary who misappropriates the appliance key and creates a new subordinate CA.