What Is mTLS?
Mutual Transport Layer Security (mTLS) is a process that establishes an encrypted TLS connection in which both parties use X.509 digital certificates to authenticate each other. MTLS can help mitigate the risk of moving services to the cloud and can help prevent malicious third parties from imitating genuine apps.
Great. I think I got it. But just in case, tell me the whole thing again.
A Quick Review: How TLS Works
Okay, but first, let’s back up a step. When web browsers want to connect to a secure web server, for example https://www.f5.com, they use the Transport Layer Security (TLS) protocol. This provides the ability not only to scramble and protect private communications but to verify that the server the browser is connecting to does indeed belong to F5. We may never have visited www.f5.com before, and yet our web browsers trust that site’s identity from the first moment we visit. Our web browser’s ability to do this is made possible thanks to the use of trusted third parties (TTPs). In the case of TLS, the TTP is a certificate authority (CA), which creates and issues X.509 digital certificates to website owners once they prove they own a domain name.
The web browser can trust the web server because they both trust the third party (the CA). In order for this trust to work, the web browser must have existing knowledge of the CA. That’s why our devices and web browsers come preloaded with certificates for hundreds of public CAs. These CAs form the “anchor” of trust between our web browsers and the websites we might want to visit.
The following steps are required for a web browser to trust the certificate that a web server provides. The steps are illustrated in Figure 1:
- The CA’s public certificate must already exist in the web browser or operating system. This provides the anchor upon which all subsequent trust relationships are based.
- The web server must prove ownership of the domain name for which it requests a certificate. Once ownership is verified, the CA issues a new certificate and digitally signs it using its own private key. The new certificate is installed on the web server.
- The web browser visits the website and, as part of the TLS connection, the web server sends its certificate to the web browser.
- The web browser uses the CA’s public certificate to check the signature of the certificate. If the signature is verified, the web browser knows it is connected to a web server that has proven ownership of that domain.
If you’re still a little fuzzy and want to learn how TLS works, visit the F5 DevCentral YouTube channel, which contains a series of videos explaining the process.
Okay, but you’ve just described everyday TLS. What is mTLS?
We’re almost there, don’t worry.
Now, Back to mTLS
In this example, only one party, let’s call her Alice, has performed authentication. The second party, let’s call him Bob, has not authenticated Alice using certificates (see Figure 2 below). For the most part, he doesn’t need to. Bob knows that millions of people visit his website and he has his own way of verifying his customers—he can ask Alice to provide a username and password after establishing the TLS connection. Using credentials is not nearly as secure as performing cryptographic verification using digital certificates, but it’s generally good enough for what most people do over the web, such as shopping or posting cat videos.
But let’s say Alice and Bob do need stronger authentication. Maybe they’re dealing with extremely high-value financial transfers or sending sensitive information. Maybe there’s a good chance that a malicious actor can steal Alice’s password and take her place. Bob may want or need to cryptographically verify that Alice really is who she says she is. In this case, they might want to mutually authenticate each other. That is to say, not only does Alice verify Bob’s identity, but Bob also authenticates Alice’s identity (see Figure 3). Over the web, this can be performed using digital certificates and mutual TLS.
Is mTLS a New Protocol?
No, not at all. Mutual authentication is part of the TLS standard and has been part of the specification since it was called Secure Sockets Layer (SSL).1 Any web server that uses TLS to secure its traffic should be capable of mutual authentication. In order to implement mutual authentication, the server needs to specifically ask the client for its certificate, however, most web servers are not configured to do this by default.
Figure 4 shows a simplified version of a TLS 1.2 connection, known as the “handshake.” The majority of websites on the Internet skip steps 4 and 5. For sites and services that need to perform mutual authentication, the server, at step 4, will send a message to the client asking it to provide a certificate (as well as telling it which CAs it accepts certificates from).
If you want to see client certification authentication in action head over to https://badssl.com to test it out (don’t worry, despite its name this site is perfectly safe and is actually a great way to test SSL/TLS configurations). In order for this test to work you must first install the client certificate on to your system (get it here: Certificate Downloads — badssl.com). After you install the certificate, visit https://client.badssl.com/ at which point you should be prompted to select a certificate that you’d like to authenticate with. Your only option should be the certificate you have just installed.
Can I Use Any Certificate for mTLS?
Yes and no.
The most common standard for digital certificates is known as X.509 version 3. In fact, it is so prevalent that the same certificate format is used to enable HTTPS on web servers, digitally sign application code, secure email, and authenticate devices to corporate networks. The certificates themselves for each of these are functionally identical—only the protocol standards define the limits as to how and when they should be employed. Certificate creators (certificate authorities) often add optional “extensions” in the X.509 certificate to limit their use. It is common, therefore, to find the 1.3.6.1.5.5.7.3.2 extension present in end-user certificates, which limits them to “client authentication.”1 So, while a certificate for a web server could, in theory, be used as a client certificate, in practice this would not work since a web server should refuse a certificate labeled for client identification only. In fact, as shown in Figure 5, CAs often separate their root servers, using one to create server certificates and another for client certificates.
In addition, to presenting a valid certificate, the client must also present a trusted certificate. A client certificate must be signed by a specific TTP for the server to accept it as a way of identifying and authenticating a user. If we consider the example in Figure 1, the client will likely not care which CA signed the certificate for the f5.com web server—only that it is valid. In other words, is the f5.com certificate up-to-date, has it been revoked, is it intended for use only by f5.com, and has it been signed by any of the hundreds of root CAs that our web browsers trust? When using certificates to identify clients, be those users or devices, it is essential that only a specific CA is trusted. Otherwise, a malicious user could create a client certificate from any CA and use that to authenticate to the server.
A client may hold many client certificates, all signed by different CAs and intended for use in different environments. Therefore, when a server issues a request for a client certificate, it must indicate which CA it trusts for this connection. This helps the client automatically select the right certificate.
This seems awesome! Should I use mTLS client authentication for all my websites?
Definitely not! Client certificates and mutual authentication are appropriate for closed environments in which you have control over all users and/or endpoints. The key requirement is the ability to definitively identify a user or hardware device, and that list is finite. Since public-facing websites can potentially be accessed by millions, if not billions, of users and devices, being able to identify and distribute certificates to any visitor to your site would be impossible for all practical purposes.
Where Is mTLS Useful?
Mutual client certificate authentication can be used any time the server needs to ensure the authenticity and validity of either a specific user or a specific device. For example, a client certificate can be issued to a company-owned laptop to identify and authorize it on a corporate network. Alternatively, a client certificate could be issued to an employee and stored on a smart card, which then allows the employee to gain access to applications or restricted areas of a building.
In practice, mTLS can identify and authorize the following:
- Devices onto a corporate network.
- Users into applications.
- Content delivery network (CDNs) or cloud security services to back-end web servers.
- Business-to-business (B2B) data exchanges that use APIs.
- Internet of Things (IoT) sensors, such as remote traffic cameras.
- Microservice architectures in which each microservice must ensure that each component it communicates with is valid and not tampered with.
Connecting Cloud Services and On-Premises Servers
A perfect use case for mTLS is an e-commerce platform that uses a CDN to help deliver its website to customers around the world (see Figure 6). A visitor to the site performs a standard (one-way authenticated) TLS connection with the CDN, but the CDN performs a mutual (two-way authenticated) connection to the “origin” web server. The e-commerce website (and, by extension, the CDN) does not want or need to perform cryptographic authentication with any customer. It is important, however, for the CDN and origin server to authenticate each other. This allows both parties to be sure that no interception is occurring that might allow an attacker to deliver malicious content to customers.
The Revised Payment Services Directive and Private APIs
For websites, APIs, or IoT systems in which the list of endpoints is known, mTLS might be a good option. The European banking legislation Revised Payment Services Directive (PSD2) is intended to increase the security of online banking and boost innovation in the financial services sector.1 For the consumer banking customer, this means being able to interact with multiple financial accounts held by different providers, all from one app. When one financial institution needs to query an account held by another, they exchange data via APIs secured over TLS. By performing mTLS, these APIs can be strongly authenticated in one of two places—at the application layer or at the transport layer.
In the example shown in Figure 7, a customer uses the mobile app provided by Bank of Alice to manage all of their accounts provided by Bank of Alice and Bob’s Bank. In this case, Bank of Alice acts as a client when querying the customer’s accounts held by Bob’s Bank. Both banks have agreed to only mutually trust certificates provided by one specific trusted third party, in this case, Trent’s Certificate Authority.
Mallory Bank wants to query the API of Bank of Alice, but since it does not have a certificate signed by Trent’s Certificate Authority, the mTLS connection cannot be established and Mallory Bank’s connection is rejected.
With personal data and sensitive financial data being exchanged over the public Internet, trust is of paramount importance. Each “client” must meet strict requirements and once vetted, is issued a qualified web authentication certificate (QWAC).1 Although these certificates still adhere to the X.509 v3 standard, they require stricter client verification before being issued.
Service Mesh Environments
Many modern applications employ a microservices architecture that separates application components into discrete services running across multiple servers, often inside containers. In order to exchange data and calculations, these services must communicate over the network. Contrast this to traditional monolithic applications that perform all communication in memory. Cloud environments, with seemingly limitless scale and flexible automation, provide an ideal place to deploy microservices-based applications, and while standard TLS can encrypt the communication between these microservices, it still leaves open the possibility of someone tampering with any of the services.
Using a “service mesh” allows application owners to govern the service-to-service traffic. A service mesh can centralize the management of microservices, and allows you to control both ends of the connection, using mTLS to encrypt and authenticate data on the wire. Figure 8 shows the high-level interactions of mutually authenticated TLS sessions in a service mesh environment.
Does mTLS Have Any Drawbacks?
Digital certificates can provide strong guarantees of identity and trust so long as some important caveats are well understood.
Identity Verification
A digital certificate is only as trustworthy as the process for identifying the individual requesting the certificate. If the process for identifying, vetting, and verifying the user or device is not robust enough, then an unauthorized identity may be able to request a certificate that is then blindly trusted by any service to which it is presented. All certificates are created equal, regardless of whether they are issued by a weak identity process or a strong identity process. The party requesting the client certificate must understand the context under which the certificate is issued.
The problem isn’t around the cryptographic strength of digital certificates but the implied level of trust we have when using them. We understand the weaknesses of credentials, so we often ask users to implement multifactor authentication. This leads us to the next concern—the security of private certificates.
Security of Private Certificates
Perhaps the greatest weakness of digital certificates is that they are so strongly trusted. Since a digital certificate is impossible to forge, we must assume that the certificate holder is the person or device to which it was initially issued. This means that the certificate must be stored securely. If it is stolen, then a malicious party will be able to assert that it is a valid client. Client certificates should not be used in environments in which the user or device is not trusted. If the client cannot be fully trusted, then the certificate must be protected as much as possible. For example, it should be stored within a hardware security module or password protected.
Step-Up Authentication in TLS 1.3
Prior to TLS 1.3, it was possible to delay the mutual authentication step to a time after the initial handshake. This is known as step-up authentication or post-handshake authentication. A client (for example, a web browser) could visit a secure HTTPS website and browse anonymously. That is to say, no mutual TLS authentication needed to happen immediately. Upon navigating to a restricted area of the website, the server could request a new TLS handshake, during which it 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 is designed to act similarly to renegotiation, though not all current TLS 1.3 implementations support it. This means that implementing TLS 1.3 may break the step-up or post-handshake authentication feature, depending on the application or service hosting the secure HTTPS website.
Conclusion
While mTLS is great for authenticating two parties during the initial SSL/TLS handshake, it is generally unsuitable for public websites since the management and security of digital certificates is complex. Instead, it is best for environments with a fixed number of clients, such as network devices, IoT sensors, laptops, or mobile phones. mTLS can also be extremely useful in securing microservices-based applications and for protecting connections between CDNs and origin servers that reside in corporate data centers.
Recommendations
When using a CDN or hosted security solution, mTLS is strongly recommended for securing the connection between the cloud provider and the origin web servers. You can choose either a public or a private CA to create the digital certificates for the cloud service and the on-premises web servers. The root certificates of the CA must be installed in both the cloud service and the on-premises web servers.
Microservices and service mesh-based architectures are increasingly deployed into the cloud. It is therefore essential to maintain control over which service is trusted. Performing mTLS between services and the ingress controller is a good way to prevent tampered or malicious services from interacting with an application.
Whether staff members need to work remotely or you’re required to connect to and manage IoT devices, it is essential to authenticate and verify the device calling home. We recommend using digital certificates and mTLS to manage the identities of those devices and to ensure a secure and trusted connection.
