title

Securing communication over APIs between machines and the applications and services they run has always been a big priority for security and engineering teams. Protocols like SSL and TLS have provided enterprises with a way to encrypt data that is transferred within a network or across its boundary. 

While TLS gracefully replaced its predecessor, SSL, both protocols have shown to be vulnerable to attacks. TLS has been the target of several attacks such as Renegotiation attacks, RC4 and POODLE attacks. The exploitable vulnerabilities within TLS has left many security professionals to realize it’s simply not enough. From this, MTLS or mutual Transport Layer Security has both parties authenticate via certificates to provide an additional security measure to cross network communication.

This article will cover how mTLS works, the steps that are involved, how companies are leveraging it and some considerations to make when implementing mTLS.

What is mTLS?

In short, Mutual TLS (mTLS) is a mutual authentication mechanism. It assures that the parties at every end of a network connection are who they claim to be. This assurance is established by validating their private keys with additional verification being done by the information contained in their separate TLS certificates. mTLS is frequently used in a Zero Trust security framework to validate people, connections, and servers within an enterprise. It is also a common tactic used to shore up the security posture of an organization’s APIs to provide Zero Trust guarantees that no person, equipment, or network activity is presumed to be trusted. This helps to eliminate many unwanted and unnecessary security risks.

How do TLS and mTLS work?

TLS (Transport Layer Security) is a widely used encryption protocol on the Internet. TLS, formerly known as SSL, authenticates its server in a client-server interaction and encrypts transactions between the client and the server so that third parties are unable to read them.

There are a few critical components of TLS in order to understand how it works: 

Public key and private key

TLS employs a technique known as public-key encryption that entails the use of two keys: a public and a private key. Only the private key can decrypt anything encrypted using the public key, and vice versa.

TLS certificate

The TLS certificate is a data file that includes the public key, a declaration of who issued the certificate, and the expiration date of the certificate for the purpose of authenticating a server or device.

TLS handshake

The TLS handshake is the procedure for confirming the TLS certificate, in addition to the private key ownership of the server. Additionally, the TLS handshake specifies how encryption will be carried out when the handshake is complete.

Usually, the server has a TLS certificate and a public/private key pair, whereas the client does not. The typical TLS procedure is as follows:

1. The client interacts with the server
2. The server shows its TLS certificate
3. The client validates the certificate of the server
4. The client and server transfer information over an encrypted TLS connection

Meanwhile, mTLS provides both the client and the server a certificate, enabling both sides to use their public/private key pair to authenticate. In comparison to conventional TLS, mTLS includes the following additional steps in order to validate both parties:

1. The client interacts with the server
2. The server shows its TLS certificate
3. The client validates the certificate of the server
4. The client provides the TLS certificate
5. The client's certificate is verified by the server
6. The server provides access
7. The client and server transfer information over an encrypted TLS connection

Why is mTLS used?

mTLS ensures that traffic between the client and a server is both trustworthy and secure for both parties, securing connections that don't require a login, such as IoT devices.

mTLS protects against a variety of attacks, including:

• Malicious API requests: When it comes to API security, mTLS guarantees that only valid and authenticated users are make API requests. It prevents attackers from sending fake API calls to exploit a vulnerability or subverting the expected functionality of the API.

• Credential stuffing: Attackers present themselves as valid users with stolen credentials – likely from a data breach. Credential stuffing attacks that target businesses leveraging mTLS will not be successful without a valid TLS certificate.

• Phishing attacks: Phishing attacks frequently aim to collect user credentials, which are then used to exploit a network or software. Even when a user falls victim to such an attack, the attacker will still need a TLS certificate and a private key to use all the credentials.

• Brute force attacks: A brute force attack is when an attacker, over brute force trial and error, tries to guess a user's password, which is typically carried out by bots. Because mTLS requires simply more than just a password to gain access to an organization's network, it helps to render these attacks as futile. 

• On-path attacks: On-path attackers insert themselves between the client and the server, intercepting or altering communications. On-path attackers cannot certify with either the client or the server whenever mTLS is utilized, making that attack nearly impossible to execute.

• Spoofing attacks: Attackers can try to "spoof" (mimic) a web server to a client or the other way around. Spoofing attacks become much more difficult when both parties are required to verify their TLS certificates.

How do companies use mTLS?

In practice, companies use mTLS in the following ways:

Identify and Authorize

• • Connecting devices to a corporate network
  • Content delivery network/cloud security services into back-end web servers
  • Clients into applications
  • APIs used in business-to-business (B2B) data transfers
  • Microservice architectures where each microservice must guarantee that every component with which it interfaces is legitimate and unmodified
  • Sensors connected to the Internet of Things (IoT), like remote traffic cameras

Connecting Cloud Services and On-Premises Servers

An ideal use case of mTLS is for e-commerce platforms that use a CDN to provide its website content. A visitor to the site connects to the CDN using a regular, (one-way authenticated) TLS connection. However, the CDN connects to the "origin" web server using a mutual (two-way authenticated) connection. Both the CDN and the origin server must authenticate each other. It helps both parties ensure that there is no interception point that would enable an attacker to distribute unwanted content to clients.

The Revised Payment Services Directive and Private APIs

mTLS may be a useful alternative for websites, APIs, or IoT devices with a known list of endpoints. The Revised Payment Services Directive (PSD2), a piece of European banking regulation, aims to improve online banking security and encourages development innovation for financial services organizations. It provides the ability to use one app to manage many financial accounts from various suppliers for a consumer banking user. APIs that are secured using TLS are leveraged whenever one banking firm needs to search the account of another. These APIs can be highly authenticated either at the application or transport layer using mTLS.

Service Mesh Environments

Microservices architecture divides application components into distinct services that run across different servers, commonly inside containers, on several modernized systems. These services need to communicate through the network to transmit data while traditional monolithic applications conduct all communication in memory. Although ordinary TLS can encrypt communication among microservices, it still creates the opportunity to intercept communication from the exposed services. Application developers can control service-to-service traffic by using a service mesh. The service mesh can consolidate microservice administration and provide control over both endpoints of the connection by encrypting and authenticating data with mTLS.

What are the drawbacks of mTLS?

While mTLS offers many benefits, it is important to acknowledge some of its drawbacks. 

Private certificate security 

The fact that digital certificates are so widely trusted can be their greatest flaw. Since it is impossible to fake a digital certificate, users must presume that the license holder is the person or device to whom it was originally granted. Securing these certificates properly can mitigate risk exposure as a malicious entity can impersonate themselves as a legitimate client. Therefore, client certificates should never be used in instances where the user or device isn't really trusted. If a client cannot be completely trusted, the certificate should be protected to the greatest extent possible.

Verification of Identity 

A digital certificate is only as reliable as the mechanism for identifying the person who obtained it. An unauthorized identity can request a certificate which is then blindly trusted by any service if the clients device isn’t validated extensively enough. All certificates are ultimately produced the same, regardless of  how diligent the device’s identity is vetted. The party seeking the client certificate must be aware of the circumstances in which it is granted. 

The issue isn't with the cryptographic efficacy of the digital certificates, but rather with the implicit degree of trust with the entity requesting the certificate.

TLS 1.3 Step-Up Authentication

Before TLS 1.3, the mutual authentication step could wasn’t instantiated until the initial handshake was completed. This is referred to as post-handshake authentication or step-up authentication. A client could browse anonymously on a secure HTTPS website, meaning that no instantaneous mutual TLS authentication would be required. The server might request a fresh TLS handshake when the user navigates to a restricted portion of the website, and then it would request the client for a client certificate. This renegotiation capability was superseded by two procedures in TLS 1.3: a lightweight key update and the post-handshake client authentication. Post-handshake client authentication is supposed to work similarly to renegotiation, even though all existing TLS 1.3 implementations do not enable it.

Conclusion 

To summarize, mTLS is nothing more than an improved version of TLS (Transport Layer Security). It uses the very same protocols and technologies as TLS. The only difference is that it uses two-way verification rather than one. mTLS is currently one of the stronger solutions for protecting servers from malicious devices, but the inherent need to verify and validate the identity of the client is of the utmost importance.