There and Back Again: An HTTPS Request’s Tale, part 2

In the previous post we learned about the Domain Name System and how the browser finds the IP address of the website we want to visit. Normally the next step would be for the browser to make an HTTP request to the server, however our example url was https://www.google.com, which uses HTTPS as its protocol (the protocol identifier is located before the “://” in the url). Therefore this part of our journey will cover HTTPS. We will go over what HTTPS is, how it is different from normal HTTP, and how HTTPS establishes a secure connection between the browser and server through a process known as the “SSL handshake”.

HTTPS stands for Hypertext Transfer Protocol Secure, and is essentially just normal HTTP with additional security features added. These security features include authenticating the identity of a website and encrypting the communications between the browser and the server. They enable HTTPS to provide three important security benefits: privacy (through encryption), integrity of data (through encryption), and identification (through identity authentication).

HTTPS establishes a secure connection through a process called the “SSL handshake”. SSL stands for Secure Sockets Layer, and is the security protocol used to establish encrypted communications between the browser and the server. Another term for SSL is TLS which stands for Transport Layer Security. TLS is the more modern updated version of SSL, and has replaced SSL, however the terms are often used interchangeably or combined together into SSL/TLS.

There are four main steps in the SSL handshake:

1. The browser sends the server a list of all SSL/TLS versions and encryption algorithms that it can work with.

2. The server chooses an SSL/TLS version and encryption algorithm and sends the browser its SSL certificate. An SSL certificate is granted by a Certificate Authority which is a third party organization that grants certificates to website owners after verifying things like: the owner’s identity, the owner’s legal right to use the domain name of the website, and that the owner represents a legitimate organization.

3. The browser verifies the SSL certificate and generates a master encryption key which it copies, and sends to the server.

4. The server receives the master key, and both the browser and server use the shared master key to encrypt/decrypt communications between each other.

Now that the SSL handshake is complete, the browser can make normal HTTP requests to the server with the added security of all communications between them being encrypted. Please note that for the sake of simplicity I left out some nuances related to the generation and sharing of the master key between the browser and the server. For a more detailed overview of how HTTPS works that is also wonderfully fun see How HTTP Works… in a Comic!

Onward to the next step of our journey- the TCP handshake!