By default, the TLS protocol only proves the identity of the server to the client using X.509 certificate. The client’s authentication to the server is left to the application layer. The purpose of this check is to ensure that no fraud is involved and the data transfer between the client and server is encrypted. But what happens when there is the need to authenticate the client to the server?
Luckily, the TLS protocol offers the option of client-to-server authentication using client-side X.509 authentication. This type of authentication is referred to as mutual authentication or mutual TLS (mTLS).
What is Mutual TLS Authentication?
Mutual authentication, also known as two-way authentication, is a security process in which entities authenticate each other before actual communication occurs. In a network environment, this requires that both the client and the server must provide digital certificates to prove their identities. In a mutual authentication process, a connection can occur only if the client and the server exchange, verify, and trust each other’s certificates. The certificate exchange occurs by means of the Transport Layer Security (TLS) protocol. The core of this process is to make sure that clients communicate with legitimate servers, and servers cooperate only with clients who attempt access for legitimate purposes.
The diagram below provides a description of the mutual TLS authentication.
Figure 1: Mutual TLS Authentication. Source: Cloudflare
The Challenge of Securing Cloud Instances
With more and more businesses migrating to the cloud and taking advantage of the benefits offered by multi-cloud platforms, the question that needs to be answered is how to secure communications with the various cloud instances. Actually, the authentication of cloud-based applications to the respective backend and middleware components seems like the Achilles' heel of application security. It is important to ensure that only approved applications or processes are granted access through APIs.
A mechanism used frequently is through single, static application logins. However, in a rapidly changing world, static logins present some security challenges.
First these logins are not updated frequently. Second, it reduces the organization’s ability to monitor and audit activities because they are grouped under the identity of the application. That problem can worsen when the application is manipulated by an attacker and the credentials are stolen or compromised. If this happens, it can prove difficult to sort out which logins are legitimate application components and which logins are unauthorized.
How Mutual Authentication Fosters Application Security
The problem above can be solved by leveraging mutual TLS authentication. Just like a client (i.e. a browser) authenticates the identity of a website by validating the server certificate, so too can the server validate the client. In the case of cloud-based applications, because HTTP is the transport for the API, we can enable mutual authentication between components. In fact, we can limit the range of certificates acceptable to what is expected by requiring a specific certificate fingerprint or serial number from a particular certificate authority. Mutual authentication can be used either alone or in conjunction with a password or an identity provider.
However, employing a TLS mutual authentication strategy in a cloud environment has a few dependencies. First, as we discussed beforehand, mutual TLS authentication is optional. Therefore, we must customize the API to enable TLS mutual authentication. Luckily all major PaaS vendors offer detailed step-by-step instructions on how to enable mutual authentication (see more for AWS, Azure and Google).
Advantages of Mutual Authentication
TLS mutual authentication has a few advantages from a security standpoint. Most obviously, it means relying less on insecure passwords or static secret values. Using a password or secret creates significant overhead and friction if you are to follow reasonable security practices—changing the password periodically, monitoring its usage, enforcing complexity, making sure it is appropriately protected. TLS mutual authentication removes this hassle. While setting up mutual authentication is not as straight forward as setting up a password, the amount of overhead required to manage certificates—especially if you automate the process—is far less than managing passwords.
Another advantage is that the certificate and corresponding private key are less portable than a password. While these credentials can be stolen or compromised just like any other digital credential, it requires more sophisticated skills for an attacker seeking to impersonate a remote API caller. From a monitoring and auditing point of view, using multiple certificates organizations can keep track of which component makes an API request with more granularity.
It Is All About Effective TLS Certificate Management
However, these certificates are machine identities that need to be administered and managed effectively, otherwise trust will be doomed. For example, TLS certificates do expire. If you generate a certificate now and load it into your application, you should be sure to remember to reissue a new certificate when the old one expires. If you forget, your organization will face potential catastrophic outages. It is important not only to keep track of certificate expiration dates and be proactive about replacing expired certificates, but also to automate and manage effectively the whole certificate lifecycle.
Related posts
- Moving to the Cloud Doesn’t Mean You Can Forget about Key Management
- The “Egregious 11” Have Spoken: Machine Identities in the Cloud Need to Evolve
- Why Zero Trust in the Cloud Requires On-demand Machine Identity Protection
- Dynamism in the Cloud Complicates the Task of Securing Machine Communication
