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.
In mTLS, however, both the client and server have a certificate, and both sides authenticate using their public/private key pair.
- Client connects to server
- Server presents its TLS certificate
- Client verifies the server’s certificate
- Client presents its TLS certificate
- Server verifies the client’s certificate
- Server grants access
- Client and server exchange information over encrypted TLS connection
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:
- 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
- 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.
- 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.
- 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.)
- 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.
- 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.
RFC 6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (rfc-editor.org)
The visible face of the Internet largely consists of services that
employ a client-server architecture in which an interactive or
automated client communicates with an application service in order to
retrieve or upload information, communicate with other entities, or
access a broader network of services.
When a client communicates
with an application service using Transport Layer Security [TLS] or
Datagram Transport Layer Security [DTLS], it references some notion
of the server’s identity (e.g., “the website at example.com”) while
attempting to establish secure communication.
Likewise, during TLS
negotiation, the server presents its notion of the service’s identity
in the form of a public-key certificate that was issued by a
certification authority (CA) in the context of the Internet Public
Key Infrastructure using X.509 [PKIX].
Informally, we can think of
these identities as the client’s “reference identity” and the
server’s “presented identity” (these rough ideas are defined more
precisely later in this document through the concept of particular
In general, a client needs to verify that the server’s
presented identity matches its reference identity so it can
authenticate the communication.
Many application technologies adhere to the pattern just outlined.
Such protocols have traditionally specified their own rules for
representing and verifying application service identity.
Unfortunately, this divergence of approaches has caused some
confusion among certification authorities, application developers,
and protocol designers