Mutual TLS (mTLS)

Everyone in Security profession knows what TLS — Transport Layer Security — is. First “version” of the protocol — Secure Socket Layer (SSL) 2.0 — was published in 1995. Since then, it has come a long way: SSLv2 (1995–2011), SSLv3 (1996–2015), TLSv1 (1999–2020), TLSv1.1 (2006–2020), TLSv1.2 (2008-current), TLSv1.3 (2018-current). But the fundamental idea behind the protocol hasn’t changed much, and is very simple: Use Public Key cryptography to authenticate the server, and use a Key Exchange algorithm to agree on a symmetric encryption key between the client and the server for encrypting the network traffic. This simple idea has been the backbone of Internet-based commerce and security-sensitive transactions.

There are few major scenarios of the protocol use. 1. The client does not authenticate the server. Well, that sounds dumb but it is possible. 2. The server is authenticated but the network traffic is not encrypted. 3. Not only the client authenticates the server, but the server also authenticates the client using Public Key cryptography as part of TLS protocol handshake. And, this 3rd scenario is called Mutual TLS, or mTLS.

What use-case does mTLS serve?

When you login to LinkedIn or web-based email account, the server is authenticating you — using your account credentials — and your web-browser (client) is authenticating the server using the server’s digital (X.509) certificate during TLS protocol handshake. In this case, the server is authenticating the end-user, not the client (aka User-Agent). To prompt the end-user for user ID and password, the server needs to allow the client to connect without any authentication and let the web-application Login screen be accessed by the end-user. And, this all makes sense.

However, consider a scenario where either there is no end-user involved (service to service communication or Service Mesh architecture), or there is a requirement to authenticate User-Agent (or the program establishing network connection) in addition to the end-user (or application level user). Why do we need to authenticate both User-Agent as well as end-user? Think of it as a second factor (2FA) authentication, or applying defense-in-depth principle layering application level authentication (what you know) on top of network level authentication (what you have). Mutual TLS, or mTLS is best suited for such scenarios.

Can mTLS be an optional requirement?

I cannot answer this for you because I cannot evaluate your specific scenario. But I’ll walk through my thoughts on this.

When a server chooses to support mTLS (client certificate authentication) in addition to the application level authentication (secret, password, API key, etc), someone is thinking that resources provided or data hosted by the server are worthy enough of 2FA or defense-in-depth security. If criticality of the resources as well as sensitivity of the data varies based on application level user, then perhaps not all users need mTLS connection. However, if the server resources (or data) are shared or common — even partly — among the application level users, then optional mTLS means — those resources are protected consistently (100% of the times) by only application level authentication.

So, imagine, your proverbial castle has a strong thick steel door (i.e. supporting mTLS) on the front and has a regular wooden door (i.e. allowing 1-way TLS) at the back. Is the thick steel door (in other words, supporting mTLS) of any use when someone can easily get in from the backdoor?

(Note: This blog post is not associated with my current or former employers. Apologies in advance if I missed providing credits to any source I referenced.)