How TLS Works — Part 1

TLS (Transport Layer Security) is used to secure Internet communication (web-browsers to servers) as well as inter-server communication, for example, application servers commuicating with databases. Using TLS correctly guarantees that hackers and bad-actors can never evesdrop your communication (communication is encrypted using a virtually unbreakable cryptographic cipher) and also confirms the identity of the communicating parties to each other (impersonation is almost impossible).

We at RunX foster a security-first mindset; and so, unsurprisingly, every bit of infrastructure stood up by our flagship product, Opta, is secured using implementations of TLS. So how exactly does TLSwork?

To understand TLS, we need to understand how Public Key cryptography works. There is a lot of good documentation available for this, but for our TLS understanding purpose lets look at a picture:

Public Key Encryption: The information sender uses the public-key of the information receiver to encrypt the message. No one can decrypt the encrypted information without the private key of the information receiver. The Information receiver uses their private key to decrypt the information.

The information sender uses the public-key of the information receiver to encrypt the message. No one can decrypt the encrypted information without the private key of the information receiver. The Information receiver uses their private key to decrypt the information. In this figure, the public and private key belong to the information receiver. These are sometimes referred to as key-pairs since they exactly complement each other.

There is one more aspect we should mention here; either the public key or private key can be used to encrypt information, and the corresponding complementary key (private key or public key) can be used to decrypt it. In the figure, we used the public key to encrypt the information and the private key to decrypt the infromation, but we could use the private key to encrypt information, then the public key to decrypt it. Usually, the information receiver freely gives away the public key so that any sender can use it to encrypt information to send to the receiver. The receiver can use the private key of the key-pair to decrypt the information.

After that detour explaining Public Key Encryption, we are ready to understand how TLS works. We will use the example of a web browser client being the information sender and a server being the information receiver. The favorite scenario fitting this example is a web browser client user wishing to transact with a bank server over the Internet.

Get Sachin Agarwal’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The first step in setting up a secure link is to download the server’s public key. But before the web browser client can use the server’s public key to establish secure communication with the bank server, there is the additional problem of verifying that the public key being used is in fact the public key of the bank server and not a spurious public key that a hacker supplies to the web browser client. After all, we don’t want the web browser client being duped into securely communicating with the hacker’s server instead of the legitimate bank server!

This is where well-known certificate authorities come into play. The bank server gets its public key signed by a certificate authority, as showing in the above figure. “Signing” means that the certificate authority takes the public key of the bank, verifies the bank and its domain (e.g. https://mybank.com infact belongs to the real bank Mybank), and uses PKE with its own private key (the plaintext information being the public key supplied by the bank in this case), to come up with a signed “certificate” for the bank.

Certificate authorities publish their public keys that come pre-installed in web browser clients. The web browser client can use the public key of the certificate authority to verify that the certificate being downloaded from the bank’s website is in fact correctly signed by this well known certificate authority (as we discussed earlier, information encrypted with the private key can be decoded by the corresponding public key of the key pair). If the certificate checks out, then the client can be assured that the server it is communicating to is in fact the legitimate server.

With this Public Key Infrastructure (public-private keypairs, certificate authorities) in place we have the building blocks to implement TLS! We’ve included a couple of excellent references below if you want to continue learning the details of TLS.

References

[1] Transport Layer Security https://en.wikipedia.org/wiki/Transport_Layer_Security#SSL_1.0,_2.0,_and_3.0

[2] TLS Basics https://www.internetsociety.org/deploy360/tls/basics/