How it works: HTTPS

Hyper Text Transport Protocol (HTTP) is an internet protocol that governs how a browser communicates with a server to present a webpage on your device. The ‘S’ on the end of this stands for ‘Secure’, which basically just means that everything is encrypted. Therefore, to understand how HTTPS works, we need to first understand how HTTP works.

How does HTTP work?

When you type in a website into your browser, your computer sends a request to the website with some information about who you are (information about your computer) and what you’re wanting to get in return. Typically, the request sends information such as your IP Address (so that the website knows who to send data back to), the type of browser you’re requesting from, some authentication details (if it’s a site you’re logged into or logging into), and the page that you’re requesting, among other information.

Once the website server receives this request, it will likely do some verification stuff on its end, then it will send a message back to your computer containing the source code of the webpage. The browser then takes this source code and renders it into something that is presentable and more easily human-readable.

I’ve written a little bit more on source code of websites in this blog describing browser-in-the-browser attacks.

Where does the ‘S‘ come into play?

The ‘Secure’ part of HTTPS is the encryption, authentication, and integrity checks of the data sent between your computer and the website.

What's the process?

Getting a bit more technical: when you first type in the URL of a website and click enter, your computer first sends sends some request to some other servers to grab the location (IP Address) of the server (these are called DNS requests). Your computer then sends an initial “hello” to the website server, with some information about what sort of encryption algorithms it can support, a randomly generated value (part of something called the diffie-hellman key exchange, which is the algorithm used to generate the keys used to encrypt the traffic between your computer and the website), and some other data.

The server then responds to your message with a “hello”, along with the chosen encryption algorithm and a randomly generated value (the other part of the diffie-hellman key exchange). The server then sends another message containing the website SSL Certificate (Secure Socket Layer, which is a layer in the networking model known as the TCP/IP Model), its public key, and details to verify the server is who they say they are.

Your computer then takes this certificate and public key, and verifies it with a third party organisation known as a CA (Certificate Authority). Once verified, your computer generates a ”pre-master secret” (the next stage of the diffie-hellman key exchange) with the public key sent earlier from the server, and sends this secret to the website server.

Just to quickly summarise what has happened so far, both the website server and your device have generated random numbers and sent them to each other. From here, your computer generates some other secret value that it then encrypts with the public key given by the website server, and sends that secret value to the website server. Read more on how public keys (asymmetric keys) work.

From here, both the server and your computer use the two randomly generated values from earlier, along with the “pre-master secret“ to generate the same master secret (the final stage of the diffie-hellman key exchange), which is then used to create encryption keys with the chosen encryption algorithm determined at the start of the interaction. Both the server and the computer then send messages to each other verifying that they have the same encryption setup, and the encrypted session is started.

The image above is a rough outline of the process described. In this case, the 'Client' is your computer, with the arrows indicating the direction of messages. Note that this is a rough outline of initial setup interactions, with the actual process differing slightly.

The dotted lines indicate unencrypted traffic, with the solid lines indicating encrypted traffic.

Where else is this used?

The method described above is known as the SSL/TLS handshake method. This method is used in a wide range of communication methods across the internet (not just visiting websites). To name a few, this method is also used in:

• Email - SMTPS (Simple Mail Transfer Protocol Secure), IMAPS (Internet Messaging Access Protocol Secure), etc.
• File transfer - FTPS (File Transfer Protocol Secure), SFTP (SSH File Transfer Protocol)
• Messaging apps like Signal
• Remote Desktop Connections
• Online video calls
• VPNs

All in all, this method is used all across the internet to secure services and encrypt messages so that only those that are intended to see these requests see them.