Security strategy: zero trust model with mTLS

Prologue

When I worked at Mastercard, I had an opportunity to contribute to an organization's effort to upgrade backend services to support optional mTLS for a new client from the middle east. Due to the country policy, all the data handled within our application had to be on-premise and this was the first time I heard about "Zero Trust Architecture" which sounded pretty cool!

Terminologies explained:

"On-premise" means that software, systems, data, and infrastructure are installed and operated within an organization's own facilities, such as an office building or data centre in a certain region, etc.
"Zero trust" is a cybersecurity framework that assumes no subject in an information system is trusted by default.

What is mTLS?

A mutual transport layer security is an encryption protocol often used in a zero trust security framework. To better understand, we first need to know about the following three important building blocks:

Public and Private keys
- Anything encrypted with a public key can be decrypted only with the private key
- Anyone can view the public key by looking at the domain's or server's TLS certificate
TLS Certificate
- A data file containing information about server's or domain's identity, public key, and statement of certificates (issuer, expiry date, etc)
TLS handshake
- A process for verifying the TLS certificate and the server's possession of the private key

How does mTLS work?

In TLS, normally, the server has a TLS certificate and a public/private key pair while the client doesn't. TLS is established in the following manner:

Client connects to the server
Server presents its TLS certificate
Client verifies the server's certificate
Client and server exchange information over encrypted TLS connection

On the other hand, in mTLS, both client and server have a certificate, and both sides authenticate using their public/private key pairs. mTLS is established in the following manner (additional steps in bold):

Client connects to the 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

What's unique about mTLS?

As both clients and servers need to verify certificates, there has to be a central authority, so called, "Root" TLS certificate. This enables an organization to be their own certificate authority and it is self-signed, meaning organizations create it themselves (if they have their own private network or internet service provider). Thus, authorized clients and servers have to correspond to this root certificate.