Mutual TLS (mTLS)

             Why use mTLS?

When you buy something from Amazon, for example, all your credit card information flows from your browser to Amazon’s servers over TLS, and no one in the middle can see what it is. When you log in to Facebook, your credentials flow from your browser to Facebook’s servers over TLS, and no one in the middle can intercept the communications and find out what those are. 

TLS protects communications between two parties for confidentiality and integrity. Using TLS to secure data in transit has been a practice for several years.

Apart from protecting data in transit for confidentiality and integrity, TLS helps a client application identify the server that it communicates with. In the Amazon example, the browser is the client application, and when it talks to Amazon over TLS, it knows what it talks to as a result of the security model and the infrastructure built around TLS. If Amazon wants to expose its services over TLS, it must have a valid certificate that’s trusted by all the client applications that want to communicate with it.

A certificate represents the corresponding server’s public key and binds it to a common name. Amazon’s public certificate (see figure 6.1 in the next section), for example, binds its public key to the www.amazon.com common name. The most important and challenging part of TLS is how we build trust between a client and a server.

Building trust between a client and a server with a certificate authority

How do you build trust between Amazon and all the browsers (client applications) that want to access it? A third party that’s known to (and trusted by) all the client applications signs the certificates given to services such as Amazon. This third party is known as a certificate authority (CA). Anyone who wants to expose services that are protected with TLS over the web must get their certificates signed by a trusted CA.

Few trusted CAs are available globally, and their public keys are embedded in all browsers. When a browser talks to Amazon over TLS, it can verify that Amazon’s certificate is valid (not forged) by verifying its signature against the corresponding CA’s public key that’s embedded in the browser. The certificate also includes the hostname of Amazon (which is the common name) so that the browser knows it’s communicating with the right server. Figure 6.1 shows the certificate issued to www.amazon.com by the DigiCert Global CA.

Figure 6.2 mTLS among microservices lets those services identify themselves. All the microservices in the deployment trust one CA.

To take part in a communication channel secured with mTLS, both the server and the client must have valid certificates, and each party must trust the issuer of the corresponding certificates. When mTLS is used to secure communications between two microservices, each microservice can legitimately identify who it talks to, in addition to achieving confidentiality and integrity of the data in transit between the two microservices

HTTPS is HTTP over TLS

When you communicate with Amazon over TLS, the browser’s address bar shows HTTPS instead of HTTP. HTTPS runs on TLS; HTTPS relies on TLS to provide security in the communication channel.

TLS can be used by any application-layer protocol to make communications secure, not just HTTPS. A Java program can talk to a database by using Java Database Connectivity (JDBC), for example. To secure the JDBC connection between the Java program and the database, you can use TLS. Also, when an email client wants to talk to a server over a secured communication channel, it can use Simple Mail Transfer Protocol (SMTP) over TLS. There are many such examples, and these are but a few.