What is mutual TLS (mTLS)?

Typically with HTTPS communication, the authentication works only one way: the client verifies the identity of the server. For applications that require the load balancer to authenticate the identity of clients that connect to it, Load Balancers support mutual TLS (mTLS).

Mutual TLS, or mTLS for short, is a method for mutual authentication. mTLS ensures that the parties at each end of a network connection are who they claim to be by verifying that they both have the correct private key. The information within their respective TLS certificates provides additional verification.

With mTLS, the load balancer requests that the client send a certificate to authenticate itself during the TLS handshake with the load balancer. You can configure a trust store that the load balancer uses to validate the client certificate’s chain of trust.

mTLS is often used in a Zero Trust security framework to verify users, devices, and servers within an organization. It can also help keep APIs secure.

Zero Trust means that no user, device, or network traffic is trusted by default, an approach that helps eliminate many security vulnerabilities.

What is TLS?

Transport Layer Security (TLS) is an encryption protocol in wide use on the Internet. TLS, which was formerly called SSL, authenticates the server in a client-server connection and encrypts communications between client and server so that external parties cannot spy on the communications.

There are three important things to understand about how TLS works:

1. Public key and private key

TLS works using a technique called public key cryptography, which relies on a pair of keys: a public key and a private key. Anything encrypted with the public key can be decrypted only with the private key.

Therefore, a server that decrypts a message that was encrypted with the public key proves that it possesses the private key. Anyone can view the public key by looking at the domain’s or server’s TLS certificate. This follows below steps:

1. Verify proof of possession of the private key of the certificate presented by the client.
2. Validate client certificates in either of two modes:

Mode 1: Reject requests if we cannot validate the client certificate chain against a trust store.

Mode 2: Pass all requests to the backend even if they don’t provide a client certificate.

2. TLS certificate

A TLS certificate is a data file that contains important information for verifying a server’s or device’s identity, including the public key, a statement of who issued the certificate (TLS certificates are issued by a certificate authority{CA}), and the certificate’s expiration date. Performing client certificate validation against an uploaded PKI anchor.

3. TLS handshake

The TLS handshake is the process of verifying the TLS certificate and the server’s possession of the private key. The TLS handshake also establishes how encryption will take place once the handshake is finished.

How does mTLS work?

Normally in TLS, the server has a TLS certificate and a public/private key pair, while the client does not. The typical TLS process works like this:

1. The client connects to the server
2. The server presents its TLS certificate
3. The client verifies the server’s certificate
4. Client and server exchange information over an encrypted TLS connection

In mTLS, however, both the client and server have a certificate, and both sides authenticate using their public/private key pair. Compared to regular TLS, there are additional steps in mTLS to verify both parties:

1. The client connects to the server
2. The server presents its TLS certificate
3. The client verifies the server’s certificate
4. The client presents its TLS certificate
5. The server verifies the client’s certificate
6. Server grants access
7. Client and server exchange information over an encrypted TLS connection

Certificate authorities in mTLS

The organization implementing mTLS acts as its own certificate authority. This contrasts with standard TLS, in which the certificate authority is an external organization that checks if the certificate owner legitimately owns the associated domain.

A “root” TLS certificate is necessary for mTLS; this enables an organization to be its/their own certificate authority. The certificates used by authorized clients and servers have to correspond to this root certificate. The root certificate is self-signed, meaning that the organization creates it themselves. Note: This approach does not work for one-way TLS on the public Internet because an external certificate authority has to issue those certificates.

Why use mTLS?

mTLS helps ensure that traffic is secure and trusted in both directions between a client and server. This provides an additional layer of security for users who log in to an organization’s network or applications. It also verifies connections with client devices that do not follow a login process, such as Internet of Things (IoT) devices.

mTLS prevents various kinds of attacks, including:

1. On-path attacks: On-path attackers place themselves between a client and a server and intercept or modify communications between the two. When mTLS is used, on-path attackers cannot authenticate to either the client or the server, making this attack almost impossible to carry out.
2. Spoofing attacks: Attackers can attempt to “spoof” (imitate) a web server to a user, or vice versa. Spoofing attacks are far more difficult when both sides have to authenticate with TLS certificates.
3. Credential stuffing: Attackers use leaked sets of credentials from a data breach to try to log in as a legitimate user. Without a legitimately issued TLS certificate, credential stuffing attacks cannot be successful against organizations that use mTLS.
4. Brute force attacks: Typically carried out with bots, a brute force attack is when an attacker uses rapid trial and error to guess a user’s password. mTLS ensures that a password is not enough to gain access to an organization’s network. (Rate limiting is another way to deal with this type of bot attack.)
5. Phishing attacks: The goal of a phishing attack is often to steal user credentials, then use those credentials to compromise a network or an application. Even if a user falls for such an attack, the attacker still needs a TLS certificate and a corresponding private key in order to use those credentials.
6. Malicious API requests: When used for API security, mTLS ensures that API requests come from legitimate, authenticated users only. This stops attackers from sending malicious API requests that aim to exploit a vulnerability or subvert the way the API is supposed to function.

Websites already use TLS, so why is mTLS not used on the entire Internet?

For everyday purposes, one-way authentication provides sufficient protection. The goals of TLS on the public Internet are:

• To ensure that people do not visit spoofed websites
• Keep private data secure and encrypted as it crosses the various networks that comprise the Internet, and
• Make sure that data is not altered in transit. One-way TLS, in which the client verifies the server’s identity only, accomplishes these goals.

Additionally, distributing TLS certificates to all end user devices would be extremely difficult. Generating, managing, and verifying the billions of certificates necessary for this is a near-impossible task.

But on a smaller scale, mTLS is highly useful and quite practical for individual organizations, especially when those organizations employ a Zero Trust approach to network security. Since a Zero Trust approach does not trust any user, device, or request by default, organizations must be able to authenticate every user, device, and request every time they try to access any point in the network. mTLS helps make this possible by authenticating users and verifying devices.

Note:

• This product/feature is covered by the Pre-GA Offerings Terms of the Google Cloud
• This product/feature is supported by Microsoft Azure
• This product/feature is supported by AWS
• This product/feature is supported by OCI