When using mutual TLS (mTLS), the client authenticates the server by checking whether the server’s certificate is signed with a trusted CA certificate, i.e. a certificate that exists in its trust store. And vice versa, the server authenticates the client by checking the client’s certificate against its truststore. Both authentications are done at TLS level. Mutual TLS thus requires truststores and keystores on both the client and server side. One-way TLS only requires a keystore on the server side, and a truststore on the client side. So one-way TLS requires a simpler client setup, because it does not need a client specific keystore. But how does authentication work with own-way TLS. Specifically, how does one protect againts a man-in-the-middle attack?

Flow of one-way TLS session setup

TLS handshaking in a nutshell

  1. Client gets a signed certificate from the server. The CA signature on it authenticates the server for the client, just as with mTLS.

  2. Client generates a secret session key and encrypts it with Public key from the server.

  3. Server receives the encrypted key and decrypts it with its Private key.

The client and the server can now safely send each other messages by using the session key and symmetric encryption. So the client now has a secure session, aka. secure channel, with the server.

NB. A man-in-the-middle can intercept the encrypted message from the client. However, he cannot decrypt it to get the session key. So he cannot read nor modify any of the messages.

Authentication part

  1. Client sends its credentials (eg. username/password) to the server.

  2. Server side application verifies those credentials.

Server application has now successfully authenticated the client.

NB. This authentication is done at application level.

Initial credentials exchange

For this to work the client and server both must know the client’s credentials. The initial exchange of credentials between client and server is usually done through a second secure channel, or through an activation email. In the latter case the user on the client side sets up a session with the server and creates his/her credentials on the server. Usually the user’s email address is the username, but in any case the email address is part of the user profile. The server then sends a challenge in the form of an activation email to the client to check whether the user has actual access to that email address. This is however not very safe, since email is generally send over the internet as plain text. So a man-in-the-middle that can intercept the emails to a user can steal his/her identity. One has to trust that the email servers on the internet are difficult to crack and difficult to tap.

shadow-left