What Is Mutual TLS?

Mutual Transport Layer Security (TLS), abbreviated as “mTLS,” is a mutual authentication method. It ensures the parties at each end of a network connection are who they claim to be by verifying they both have the correct private key. The information within their respective TLS certificates provides additional verification.

The method is often used in a zero-trust security framework to verify users, devices, and servers within an organization. It can also help secure application programming interfaces (APIs).

Think of mTLS as requiring a secret password that two strangers have to utter to prove they are who they claim to be when they meet for the first time.

Read More about Mutual TLS

Before learning more about mTLS, let us tackle what TLS is first.

What Is TLS?

TLS is a widely used encryption protocol. Formerly known as “Secure Sockets Layer (SSL),” it authenticates a server in a client-server connection and encrypts communications between the client and the server so external parties cannot spy on their communications.

TLS will not work without three critical components—public and private keys, the TLS certificate, and the TLS handshake. Learn more about each below.

Public and Private Keys

TLS uses public key cryptography, which relies on a pair of keys — a public key and a private key. Anything encrypted with the public key can only be decrypted with the private key.

As such, a server that decrypts a message encrypted with the public key needs to prove it has the private key. Anyone can view the public key by looking at the domain’s or server’s TLS certificate.

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, the certificate authority, and the certificate’s expiration date.

TLS Handshake

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

So, how does TLS work? The server should have a TLS certificate and a public-private key pair while the client should not. The 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. The client and server exchange information over an encrypted TLS connection.

Now that you know more about TLS, let us move on toward learning more about mTLS.

How Does Mutual TLS Work?

Compared with TLS, both the client and server have a certificate. That said, they both have to authenticate each other’s certificate using their public-private key pair. The process thus has additional steps in bold dedicated to client and server verification.

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. The server grants access.
7. The client and server exchange information over an encrypted TLS connection.

TLS versus mTLS , What’s the Difference?

Both TLS and mTLS are helpful in different scenarios. We detailed their differences below.

If you are wondering which method to employ, it is always better to implement both. Why? While TLS secures your audience’s web browsing, mTLS ensures attackers cannot spy on any of your confidential business-critical communications.

What Is a Certificate Authority’s Role in Mutual TLS ?

The organization that implements the method can act as its own certificate authority. Note that in TLS, the certificate authority must be an external organization that checks if the owner legitimately owns the associated domain.

Implementers of the method need a root TLS certificate. This enables an organization to be its own certificate authority. The certificates authorized clients and servers use have to correspond to this root certificate. The root certificate is self-signed, meaning it was created by the organization.

Given that the method requires issuing certificates to all authorized clients and servers, it will not work on the public Internet. It will be virtually impossible to issue certificates to all Internet users. Besides, the Internet requires external certificate authorities to issue TLS certificates.

What Are the Requirements for Creating a Mutual TLS Certificate?

Configuring certificates requires organizations to follow these guidelines:

• They should use modern cryptography tools like RSA or ECDSA algorithms for key exchange.
• They must use SHA-256 or stronger cryptographic hash functions. Note that the method does not support hashing algorithms like MD4, MD5, and SHA-1.
• For client certificates:
  • They should ensure the Basic Constraints extension does not contain CA=true.
  • The Extended Key Usage extension must contain clientAuth.
  • The Extended Key Usage extension must not contain the codeSigning, timeStamping, or OCSPSigning fields.
  • The certificate must not be expired.
  • The certificate cannot be self-signed.
• For root and intermediate certificates:
  • The Basic Constraints extension must contain CA=true.
  • The Key Usage extension must be set to keyCertSign.
  • The Extended Key Usage extension should contain the clientAuth field.
  • The certificate must not be expired.

What Are the Benefits of Using Mutual TLS ?

The method helps ensure traffic coursing to and from clients and servers is secure and trustworthy. 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 like Internet of Things (IoT) devices.

In a sense, therefore, the method helps prevent the attacks below.

On-Path Attacks

On-path or man-in-the-middle (MitM) attackers place themselves between a client and a server to intercept or modify communications between the two. The method prevents client or server authentication, making the attacks almost impossible to carry out.

Spoofing Attacks

Attackers can try to spoof or imitate a web server when a user accesses it. They can also spoof a user accessing a server. That said, spoofing attacks are more difficult to perform when both servers and users require authentication via TLS certificates.

Credential Stuffing

Sometimes, attackers use leaked credentials from a data breach to log in as legitimate users. Without legitimately issued TLS certificates, though, credential stuffing cannot succeed against organizations that use the method.

Brute-Force Attacks

Typically carried out with bots, brute-force attacks occur when attackers use rapid trial and error to guess user passwords. The method ensures passwords are not enough to gain access to an organization’s network.

Phishing

Even if users fall for phishing lures, attackers still need TLS certificates and corresponding private keys to use successfully stolen credentials.

Malicious API Requests

The method ensures API requests come from legitimate, authenticated users only. This stops attackers from sending malicious API requests to exploit vulnerabilities or subvert how APIs are supposed to work.

What Are the Disadvantages of Using Mutual TLS ?

Despite the method’s many benefits, it has drawbacks, too.

Identity Verification

The certificates are only as trustworthy as the process for identifying individuals requesting them. If the process for identifying, vetting, and verifying users or devices is not robust enough, then unauthorized identities may be able to request certificates blindly trusted by any service to which it is presented. All certificates are created equal, regardless of the strength of the identity process.

Private Certificate Security

Since digital certificates are impossible to forge, we assume certificate holders are their owners. If not stored securely, it can get stolen and used by a malicious party.

TLS 1.3 Authentication

Prior to TLS 1.3, it was possible to delay the mutual authentication step after the initial handshake known as “step-up authentication” or “post-handshake authentication.” A client like a web browser can thus visit and browse an HTTPS website. No mutual TLS authentication needs to happen immediately. Upon navigating to a restricted area, however, the server requests a new TLS handshake, which would prompt the user for a client certificate.

TLS 1.3 replaced this renegotiation feature with two processes—a lightweight key update and post-handshake client authentication. Post-handshake client authentication acts like renegotiation. Implementing TLS 1.3 may break the step-up or post-handshake authentication feature, depending on the application or service hosting the HTTPS website.

If Sites Already Use TLS, Why Use mTLS , Too?

Note that one-way authentication via TLS provides sufficient protection for daily Internet uses. It ensures people do not visit spoofed websites, keeps private data secure and encrypted as it crosses various networks, and ensures data is not altered in transit.

It also addresses the extremely difficult process of distributing TLS certificates to all user devices. Admit it, generating, managing, and verifying billions of certificates for Internet users is impossible.

But on a smaller scale, mTLS is very useful and quite practical for organizations, especially those that employ the zero-trust approach. Why? The approach does not trust any user, device, or request by default so, organizations must be able to authenticate every user, device, and request every time they try to access the network. The method, however, helps make this possible.

Key Takeaways

• mTLS is a mutual authentication method that ensures the parties at each end of a network connection are who they claim to be by verifying they both have the correct private key. The information within their respective TLS certificates also provides additional verification.
• Compared with TLS, mTLS requires both the client and server to have a certificate. Both devices have to authenticate each other’s certificate using their public-private key pair.
• In the method, the implementing organization acts as the certificate authority.
• The method prevents several attacks, including on-path or MitM, spoofing, credential stuffing, brute-force, and phishing attacks. It also helps address malicious API requests.
• Despite its many benefits, it has drawbacks, too, regarding identity verification, private certificate security, and TLS 1.3 authentication.
• While TLS is sufficient for Internet security, mTLS provides additional security for organizations that employ a zero-trust approach.

Sources

• https://www.cloudflare.com/learning/access-management/what-is-mutual-tls/
• https://cloud.google.com/load-balancing/docs/mtls
• https://www.f5.com/labs/learning-center/what-is-mtls
• https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth?tabs=azureportal%2Cflask
• https://dl.acm.org/doi/10.1145/3646547.3688415
• https://docs.aws.amazon.com/elasticloadbalancing/latest/application/mutual-authentication.html
• https://www.fastly.com/documentation/guides/getting-started/domains/securing-domains/setting-up-mutual-tls-authentication/