Why

The concept of TLS/SSL has always escaped me, so I decided to take the time to understand it and to write about it. Many thanks to a friend for always entertaining my questions.

TLS vs SSL

Both TLS and SSL are used to secure internet communications. So why are there two? TLS is just the updated version of the now deprecated SSL. TLS will be the focal point of this blog post.

TLS

TLS secures a connection. An example of a secured connection would be HTTPS; HTTPS is just HTTP secured with TLS.

When a connection wants to be encrypted and secured using TLS, something needs to initialize in order to secure the connection. This something refers to a TLS handshake.

What is a secured connection? A connection is secured where both parties involved in the communication agrees on a method to encrypt and decrypt information and other parties are not privy to this. In the case of a TLS connection, both parties have to agree on a key to encrypt the decrypt communications. The TLS handshake helps to facilitate this.

TLS Handshake

All the jargons on TLS like public keys, private keys, certificates that we often hear about are ingredients necessary for the TLS handshake to occur.

Although the following is not the most comprehensive and detailed description of the handshake process, it seeks to capture the most important areas of it.

  1. Client (e.g. a web browser) tries to establish a connection to the server. It sends a client random (32-byte random number), the TLS version it can support, and other metadata to the server
  2. Server sends back a server random, and its certificate (this also contains the public key of the server)
  3. Client verifies the certificate against its CA certs store (which contains recognized CA certificates). This is to determine if the server’s certificate was issued by a trusted certificate authority (CA)
  4. After verifying the certificate, the client uses the public key (in the certificate) to encrypt a pre-master secret and sends it to the server
  5. Server receives the encrypted pre-master secret and decrypts it with its private key
  6. Both server and client generates a symmetric key using the server random, client random and the pre-master key
  7. Client and server can now encrypt messages using the generated symmetric key

Public Key & Private Key

In the past, I used to believe that a public key can only encrypt while a private key can only decrypt. This is a big misconception.

When an asymmetric keypair k1, k2 is generated. Mathematically, we can use k1 to encrypt and only k2 can be used to decrypt. Conversely, when we use k2 to encrypt, we can only use k1 to decrypt. It is our choice whether to use k1 or k2 as the public or private key.

In use cases where we want only the recipient to read the content of a message, we select a key (from the keypair, owned by the recipient) to be used to decrypt the content and keep this key private to the recipient. Hence the name, private key. To allow senders to send encrypted messages to the recipient, the other key (from the keypair, owned by the recipient) has to be distributed publicly, hence the name, public key.

That is not to say that the private key can only be used for decryption. An entity (let us use Alice) can use their private key to encrypt some metadata which can only be decrypted with its corresponding public key (which is known by everybody). By the act of successfully decrypting using the public key and assuming that no one else is supposed to be privy to the private key, we can ascertain that the metadata came from Alice. If the metadata contains the cryptographic hash of a message, we could even use this to verify that the message has not been tampered with. This act of using the private key to encrypt the hash of the message for the purpose of verification is also known as signing

EDIT:

This is very wrong. Not all algorithms allow keys to be interchanged. The only example that I know of which allows so is RSA. Even in the case of RSA, of the two keys generated, it matters mathematically which is chosen as the public or the private key..

The best way I can put it now is that a digital signature is a fn(sent_content_hash, private_key) which can be verified against the result of fn(received_content_hash, public_key)

Certificate

In the TLS handshake, we noticed that the server sends its certificate to the client. What is a certificate and how does the server gets one?

A certificate contains the public key and information of its holder and the certificate authority (CA) who issued the cert. How can we verify that the cert was indeed issued by the certificate authority? Let use what we know now about signing. The certificate was signed by the CA using their private key when issuing it, so we can verify this by using the CA’s public key, which is housed inside our certificate store.

To get a CA to issue you a certificate, we have to submit a certificate signing request (CSR) to the CA. The CSR will have to include information about your business and the public key you would like to include in the issued certificate. An underlying assumption here is that a CA will only issue a certificate after checking that the business entity (or individual) is legitimate.

Conclusion

Hope that I have given anybody who reads this post a better understanding of TLS. Many concepts were unclear to me at first, but writing this has allowed me to plug most of the gap when it comes to my knowledge of TLS. There are still concepts that are foreign (e.g. the math behind asymmetric keys), but this is enough for me now. Cheers!

References

https://www.cloudflare.com/en-ca/learning/ssl/what-happens-in-a-tls-handshake/
https://www.youtube.com/watch?v=86cQJ0MMses
https://en.wikipedia.org/wiki/Public_key_certificate
https://www.globalsign.com/en-sg/blog/what-is-a-certificate-signing-request-csr https://crypto.stackexchange.com/questions/76234/is-the-role-of-public-key-private-key-determined-arbitrarily-or-mathematically