How Does TLS Work?

Last updated on December 10

TLS is the web's standard for securely communicating over a network connection. With TLS, web clients can trust that information being shared over a network is both encrypted and secured. While most developers understand the importance of TLS, understanding exactly how TLS protects your network deserves a deeper dive. In this article, we discuss how TLS "handshakes" initiate trusted communication between clients and servers.

The TLS "Handshake"

When web browsers (clients) access a web server over HTTPS, an initial handshake occurs between the server and the client. This handshake verifies the identity of the server and dictates what encryption method / ciphers will be used to encrypt data being sent over the network. After the handshake takes place, the browser is free to send and receive encrypted data to the server.

There are six major steps to these handshakes. Each step is listed below with supplemental detail.

1. Client connects to the server

The browser (client) connects to the server and requests a secure connection. It tells the server which encryption methods it supports.

2. Client & server agree on encryption methods / ciphers

After receiving the client's request for a secure connection, the server analyzes the encryption methods and ciphers (a method of encrypting text) available to the client and chooses the best fit. It then tells the client which encryption method it will be using for the secured communication.

3. Server sends client its certificate

At this point, the server sends the client a digital certificate which verifies the server's identity. This certificate includes information about the server such as the server name, it's certificate authority (more on this later) and a public encryption key.

4. Client validates certificate

After receiving the server's digital certificate, the client validates the certificate to ensure it's communicating with a trusted source.

5. Client generates session key

Once the client trusts the server it's talking to, it uses the server's provided public key to generate an encrypted session key. It then sends this encrypted key back to the server.

6. Server decrypts key and completes handshake

After receiving the client's encrypted key, the server uses it's own private key to decrypt the session key. This validates a secure connection as only the server has access to its private key (which is needed for decrypting the client produced session key).

More on Certificate Authorities

Certificate authorities are third party institutions that verify or "sign" the certificates provided by the server. This is important because it helps protect man-in-the-middle attacks where hackers intercept and forge certificates.

By having a third party validate these digital certificates, it's more difficult for hackers to create their own phony certificates and intercept connections.

While CAs make it harder for attackers to forge certificates, they aren't fail safe. What's to stop a seasoned attacker from forging the public key provided by a CA to forge the signing of the certificate itself? Although things like certificate chains protect against these more advanced attacks, CAs themselves are not a fail safe system for man-in-the-middle attacks.

Conclusion

Fortunately, such attacks are extremely difficult and rare. By using TLS you are keeping your connection secure (at least by todays standards). While most websites already use TLS to communicate securely, it's beneficial to know whats going on under the hood. For more information on SSL/TLS, see SSL vs TLS.