Detailed Explanation of the HTTPS Encryption Process

The small lock icon in the browser address bar - when does it turn green and when does it show a red cross? Most of the time we just glanced over it and moved on. It wasn't until one day when the website we built was marked as "insecure" by the browser that we realized it wasn't as simple as that.

In fact, behind that small lock lies a complete set of sophisticated encryption procedures. Today, let's talk about what exactly happens between the browser and the server when you type in https://

Let's start with a basic concept: HTTPS is not a new protocol; it's just HTTP wrapped in an extra layer of SSL/TLS. It's like shouting on the street where everyone can hear you, but if you enter a room with encrypted glass walls, people outside can only see your mouth moving but won't be able to hear the content. This room is what the TLS protocol does.

So how was this room constructed? The core idea is quite smart: it uses two encryption methods in combination.

One type is called symmetric encryption, where the encryption and decryption use the same key. The advantage is speed, but the drawback is how to safely transfer the key to the other party? If the key is intercepted on the way, all the efforts will be in vain.

Another type is called asymmetric encryption, which involves two keys: a public key for encryption and a private key for decryption. The public key can be freely distributed, and anyone who gets it can encrypt data. However, only the person with the private key can decrypt it. The security is there, but the problem is the speed. Encrypting a few paragraphs of text is manageable, but if you want to encrypt the entire web page, the server will be overwhelmed.

The solution for HTTPS is as follows: First, a temporary key is securely transmitted using asymmetric encryption. Then, this temporary key is used for symmetric encryption to efficiently transmit data. This is similar to you first transporting the home door key (the symmetric key) using an insurance box (asymmetric encryption), and then using this home door key to enter and exit normally, which is fast and reliable.

But there is a fatal problem here: How can you be sure that the public key you have obtained is genuine?

This is the moment when digital certificates come into play. The server needs to apply to the Certificate Authority (CA) for a certificate, which contains the server's public key, domain name, validity period, and the CA's signature. The browser has a bunch of trusted CA root certificates built-in. After receiving the server certificate, it will use the public key of the root certificate to verify the signature - just like a currency detector checking if it's genuine money.

How is this trust chain put together? Suppose you enter the website address of a certain bank in your browser, and the server returns a certificate that says "This certificate is issued by the GlobalSign intermediate CA". The browser then traces back up and discovers that the certificate of the GlobalSign intermediate CA is issued by a certain root CA, and this root CA is exactly in the browser's trust list. By tracing layer by layer, until reaching the trust anchor point, this chain is considered complete.

If any of the intermediate steps go wrong - if the certificate has expired, if the domain name doesn't match, or if the issuing authority is not trusted - the browser will pop up a big red warning asking you, "Are you sure you want to continue?"

The process has been clarified. Let's go through it from beginning to end.

The first step is called "Client Hello". When you visit an HTTPS website, the browser greets the server, including its supported TLS version, list of encryption algorithms, and a client random number.

The second step is called "Server Hello". The server selects an encryption algorithm that both parties support, sends back its digital certificate, and also provides a random number generated by the server.

The third step is certificate verification. Once the browser obtains the certificate, it first checks the validity period, then verifies whether the domain name matches, and finally uses the built-in CA public key to verify the signature to ensure that the certificate has not been tampered with. After the verification is successful, the browser generates a third random number, called the pre-master key, encrypts it with the server's public key and sends it over.

Step 4: The server decrypts the pre-master key using its own private key. Now both parties have three random numbers. Each of them calculates a master key using the same algorithm, and this master key will be used for symmetric encryption in the subsequent communication. The entire process is called the TLS handshake and is usually completed within one second.

One more detail is worth mentioning. In the early days, many HTTPS protocols used RSA key exchange. The client directly encrypted the pre-master key with the server's public key and sent it over. This method had a drawback: if the server's private key was ever leaked, all the encrypted communication records previously encrypted could be decrypted.

So later, the ECDHE algorithm became popular. Both parties generated temporary key pairs independently, exchanged parameters, and then calculated the same primary key respectively. The entire process did not involve the private key in encryption; it was only used for signing and authentication. Even if the private key was later leaked, the previous communication records would still be secure. This is what is called "forward secrecy".

When it comes to this, you might wonder: Since HTTPS is so secure, why not use it throughout the entire website?

There are two reasons. Firstly, it is slow. Encryption and decryption consume CPU resources, and the handshake process involves multiple network round trips, which may make it two to three times slower than pure HTTP. Secondly, it is troublesome. One needs to purchase certificates, configure them, and remember to renew them. However, this cost is worth it as it ensures that user data is not intercepted or tampered with. For scenarios involving login, payment, and privacy, the benefits of this approach can be justified.

To be honest, that little lock icon may seem insignificant at first glance. But in fact, it is the epitome of the entire Internet trust system. The next time you see it turn green, you can know that the browser and the server have just completed a complex encryption handshake - although you don't feel anything, security has already taken place behind the scenes.