An Unintentional Secret About Automated mTLS

Transport Layer Security (TLS) and its two-way version, mutual TLS (mTLS) have an unintentional secret. Many security professionals believe that TLS and mTLS are zero trust because of the endpoint-to-server encryption they provide. But, the speed and scale of the cloud requires these protocols to create encrypted connections that are built on automated PKI certificates. There’s an ugly truth about automated certificates: they are not zero trust.

Here’s why. The workload receiving the automated certificate from an intermediate (private) certificate authority (CA) has not vetted the workload. There is no verification of its identity before the certificate is issued. The trust is in the CA that received its authority from the chain of intermediate CAs that extend back to the root domain (which is a vetted and trusted identity). The chain of trust is in the CA and not in the workload holding the cert. 

Details Matter for Zero Trust

This isn’t a secret, it’s just an important detail that is overlooked by many security professionals and developers. To be truly zero trust, a workload’s identity should be proven or tested in some manner (vetted). But when certificates are as easy to get as pushing a button there can be no trust in the workload receiving the certificate. 

For root domains (e.g. www.hopr.co) certificates mean something. They can’t be obtained unless the identity of the domain has been verified to be owned by the entity they represent. This is not the case for certificates automatically issued by cloud certificates managers. Automated certificates may comply with 509a standards, but their signing authority is not an independent third party (i.e., they are self-signed certificates) and they lack the vetted trust intended by 509a. Another problem with certificates automation is expiration. 509a certificates are designed to expire and be replaced to prevent misuse. They are semi-static, but for reasons of convenience many developers (working in dev environments) use automated certificates without an expiration date. A certificate that doesn’t expire is a serious security vulnerability if they reach a production environment. But automated certificates have yet another identity problem: each new certificate is a completely different identity from the last certificate. There is no traceability from one certificate to another, yet the workload holding the certificate hasn’t changed.

Automated certificates make sense for some use cases, such as Kubernetes clusters with an isolated cert manager or development environments where the risk of unauthorized access is low. But they should never be used in a production environment if zero trust is necessary. Without trust, an automated and self-signed  certificate, created merely to build a TLS connection, is a false promise of security.

A Zero Trust “mTLS everywhere” Alternative

It’s been said that identity is the new security perimeter. And threat actors are not missing this fact, either. As the insider threat has become more likely, the consequences of successful identity-targeted attacks are significant. Even if automated mTLS is not zero trust, many security professionals believe that there is no other option. They need the encryption; they don’t see an alternative.  But there is one, and it verifies workload identity trust in real time at the speed and scale of the cloud. And it uses a new form of automated moving target defense (AMTD) to build end-to-end encrypted communication channels (hardened tunnels) between workloads on demand.

A zero trust “mTLS everywhere” alternative is possible because of a patented technology and protocol called CHIPS™ (Codes Hidden in Plain Sight). It uses the vast amount of constantly changing Internet information (think of news stories or financial data) and a special algorithm to generate a ‘seed’ that feeds a symmetric key generator. The secret power of CHIPS is that it produces identical keys if the algorithm runs in two different places at nearly the same time. With CHIPS, two workloads in any cloud can instantly build a hardened tunnel between them without a handshake, CA certificate, and key exchange. The two workloads can confirm the trust in each other because received messages can only be decrypted and read if their keys are identical. Any untrusted messages would fail decryption. The CHIPS protocol ensures that the keys used are short-lived and replaced automatically. High frequency (HF) key rotation produces one part of AMTD that disables threat actors from discovering and misusing the keys. But there is another part that is needed to protect workload identity credentials.

Zero Trust AMTD for Workload Identity

In addition to HF key rotation, this zero trust “mTLS everywhere” alternative must verify trust in workloads before they connect with other trusted workloads. To achieve this, CHIPS is augmented with a Machine Alias ID (MAID) credential that is assigned to a workload when it is first deployed and registered with Hopr (a process performed by the enterprise’s trusted DevOps engineer). This is the moment identity trust begins, and it is preserved and frequently verified thereafter.

The MAID rotates based on the history of a workload’s communication sessions. Each time a trusted workload begins a communication session with another trusted workload, Horp is able to observe the MAID of both workloads and verify its trustworthiness. The MAID rotates at a high frequency, too, and is an essential part of the zero trust AMTD that forms a complete and more effective “mTLS everywhere” alternative.

“mTLS everywhere” is a great security goal, but it’s not practical for several reasons not yet discussed. Here are some other differences between “mTLS everywhere” and the zero trust alternative: