Mutual TLS, or mTLS for short, is a mechanism for mutual authentication between services. Also known as two-way authentication, it ensures that the parties at each end of a connection are who they claim to be. It operates on the premise of a Zero Trust security framework to verify devices, servers, and API connections.
Zero Trust verification assumes there are threats within and external to the network. Thus, no connection should be trusted automatically. It also operates on the principle of least-privilege access which involves giving each party only as much access as they need. This approach confines each user’s access to only the things they are allowed to view.
In this Mutual TLS arrangement, a connection can occur only if each party exchanges, verifies, and trusts each other’s certificate. Common examples where mTLS is useful to include:
- Authenticating user devices on a corporate network
- Business-to-Business (B2B) communication through APIs
- IoT devices
Types of Certificates Involved in mTLS
As noted earlier, mTLS relies on certificates. A certificate represents each party’s identity. Without it, they have no way of proving they are approved to access the requested resources. The handshake relies on a cryptography standard known as X.509. It is a standard that defines the format of public-key certificates. There are three types of certificates each of which meets this standard.
Root CA Certificate
The certificate is used to determine which certificate authority signed the client’s certificate. The server uses it to determine if the client should be trusted. The certificate meets the X.509 standard.
Client and Server Certificate
Both the client and server use secure certificates that also meet the X.509 standard.
How Does mTLS Work?
Authentication via this method is a complex process where each party involved must prove their identity to one another. The process operates on the concept of certificate exchange. In mTLS, both the client and server have a certificate. Each side must present certificates to verify their identity. The exchange takes place over an encrypted connection.
- The client initiates the process by sending a “hello” message to the server.
- The server responds to the client with a “hello” message and information about its SSL certificate. It also sends a random string of text known as the “server random”
- The client verifies the server’s certificate with the certificate authority that issued it
- The client retrieves the public key from the server’s SSL certificate.
- The client sends another message to the server with a random string of text that is referred to as the “premaster secret”. It also sends the public key along with this message
- The server verifies that the public key is correct and decrypts the message
- Both parties generate session keys based on the server random and premaster secret
- The client sends a “finished” message
- The server responds with a “finished” message
- The handshake is completed and communication begins.
Exceptions to This Process
The above process is the ideal scenario. However, things can go wrong that will prevent the handshake from completing successfully.
-
Certificate Expired - When verifying the client’s credentials, the server checks the current date and compares it to the validity period on the client’s certificate. If the certificate has expired, the handshake fails.
-
The Certificate Is Revoked - The server checks the client’s certificate to ensure it is not on the system’s revoked certificate list. If so, the handshake fails.
-
Certificate Not in The Certificate Chain - The server maintains a list of trusted certificate authorities (CA) that specify which certificates will be accepted. If the client’s certificate is not on that list, the handshake fails.
Why is mTLS Important?
Using mTLS is vital to ensuring two-way authentication between servers or services on a network. It helps minimize the chances of data transferred between each party from being intercepted.
More Secure Communication With Third-Party Clients
Authenticating internal requests using mTLS comes with relative certainty that each party in the transaction is valid. However, what happens when you introduce an external client? The confidence level that they can be trusted decreases. Using mTLS helps you be more confident in providing access to those external requests.
Less Reliant on Insecure Static Login Methods
Static login methods are more administrative intensive. You must stay on top of changing the password regularly, monitoring its usage, and making sure it is properly protected.
More Difficult for a Hacker to Impersonate a Remote API Call
Credentials used in this method are still susceptible to being compromised. However, the complexity requires more sophisticated skills to impersonate an authentication attempt.
Uses Fewer Network Resources
Using mTLS means your APIs talk directly to one another. As a result, you won’t need to use a network tunnel to communicate.
Use Cases for mTLS
Secure two-way communication is necessary for cloud environments. Their need to communicate over the internet makes transferring data between them subject to interception. Here are two examples of using this type of secure communication in a cloud environment.
Connecting Cloud Services with On-Premise Servers
An e-commerce site that uses a CDN to deliver content is a perfect use case for mTLS. A site visitor establishes a standard TLS connection to the server. The CDN server does not want to perform a cryptographic communication with every site visitor. There would be too many certificates to maintain. Instead, the CDN establishes an mTLS connection with the origin server to return the requested content.
Service Mesh Environments
The microservices architecture is now the preferred method of application deployment. The discrete code blocks enable the maintainability, scalability, and reusability companies require to remain agile. Each of these code blocks must communicate over a network and must do so with trusted connections. Using a service mesh to centralize the management of microservices gives developers the ability to control both ends of the communication between services.