Skip to main content

TLS Security: Understanding One-Way TLS and Mutual TLS (mTLS)

In the modern internet, it’s highly suggested to only access the resources with TLS/SSL enabled. Even most browsers prevent accessing resources with TLS/SSL expired or not enabled. This is mainly because the secure communication is not guaranteed without TLS. I think we all know at a high level that TLS encrypts traffic at transit, enabling safe and trusted communication between two parties(client and server) but not everybody cares about behind the scenes, and yeah not even me before today 😊

Terminologies​

  1. Symmetric encryption: Uses the same key for encryption and decryption.
  2. Asymmetric encryption: Uses a public key for encryption by the sender and a private key for decryption by the receiver.
  3. Keystore: A keystore stores private keys and certificates corresponding to their public keys and is used when you, as a server, need to prove your identity to a remote party (like a web browser)
  4. Truststore: A truststore, on the other hand, holds the certificates of the remote parties that you trust.

TLS(One way)​

One way TLS
One way TLS

One-sided TLS is where only the server is authenticated while the client remains unauthenticated.

  • During the TLS handshake, the server presents its digital certificate to the client.
  • The client verifies the server certificate.
    • Checks if the certificate is issued by a trusted Certificate Authority
    • Verifies the certificate validity
    • Issued to a domain the client is requesting for
  • Once all of these checks pass, the client trusts the server’s identity and starts communicating.

Browser and TLS​

  • The user requests a secure website (indicated by https in the URL). The browser initiates the TLS handshake with the server.
  • The server presents its digital certificate to the browser.
  • The browser verifies the server's certificate.
    • The browser comes pre-loaded with a list of trusted Certificate Authorities (CAs). It checks if the CA that issued the server's certificate is on this trusted list.
    • It validates the server's certificate digital signature using the trusted CA's public key. This process ensures the certificate is valid and hasn't been tampered with.
    • It verifies the certificate matches the server it's trying to communicate with. This generally means the domain name in the URL matches the Common Name (CN) or a Subject Alternative Name (SAN) in the certificate.
    • Optionally, the browser checks that the certificate hasn't been revoked.
  • Once the certificate is verified, the browser generates a secret (a random string also known as the premaster secret), encrypts it using the server's public key, and sends it to the server.
  • Both the client and the server use this shared premaster secret, along with the client and server random values shared during the initial handshake phase, to independently compute the 'master secret'.
  • The master secret, along with the client and server randoms, is then used to generate the session keys for encrypting and decrypting all data exchanged during the secure session.
info

The actual encryption that happens between the client and server uses symmetric encryption, where the same session key is used by both the client (browser in this case) and the server for encryption and decryption of the data.

Two-way TLS(mutual TLS)​

Two way TLS
Two way TLS

mTLS is an extended version of TLS where both the parties, the client and the server, undergo authentication. After the server is authenticated, the client sends its certificate to the server and the server verifies the certificate. If verification is successful, mutual trust is established.

Here is a step-by-step look at how it works:

  1. The server sends its certificate to the client (as in a typical TLS handshake).
  2. The client verifies the server's certificate (also as in a typical TLS handshake).
  3. If the server's certificate checks out, the server then requests the client's certificate.
  4. The client sends its certificate to the server.
  5. The server verifies the client's certificate against the CA certificates in its trust store.
  6. If the client's certificate is validated successfully, then the server can trust the client, and mutual trust is established.

mTLS not only asserts that the data is securely transmitted to the intended recipient but also verifies the sender's identity. This bidirectional authentication is especially useful in machine-to-machine communication where we want to ensure that not only does sensitive information arrive securely but also that it comes from a trusted source(like IOT devices).

Certificate authorities in mTLS​

For client authentication, organizations prefer not to trust all internet traffic indiscriminately. Instead, they issue certificates to a selected group of trusted clients by hosting their own Certificate Authority (CA), also known as a Private CA. The self-signed root certificate from this Private CA is installed in the server's trust store to verify client certificates issued by the Private CA. This approach differs from standard TLS, where CAs are external organizations like Let's Encrypt DigiCert, or GlobalSign - entities already trusted by most browsers and operating systems.