A beginner’s guide to HTTPS

Introduction

You add your essentials to the cart of an e-commerce website and proceed to checkout. At this moment, it asks for a payment method. You add your credit card without giving it a second thought. But why? How do you know that someone is not snooping on your network, and reading all your sensitive information? You may rightly say that you need not worry because HTTPS keeps your connection secure. But how? Let’s find out.

Glossary

Before we get into the nitty-gritty of how HTTPS secures your connections, here are a few terms you should understand at a very high level.

HTTP

Hypertext Transfer Protocol (HTTP) is the most common protocol used for transferring data over the internet. HTTPS is the secure version of HTTP. While covering this protocol would require a separate article in itself, this post should help.

Asymmetric Encryption

This involves two keys: a public key and a private key. Generally, public keys are freely distributed, private keys are kept, well, private. These two keys are mathematically related. While we won’t get into the mathematical complexities, here’s what you should know:

Data encrypted by the public key can be decrypted by the private key
A private key can digitally sign documents, and a public key can verify if the digital signature is valid and confirm that the document hasn’t been altered. In addition to verifying the integrity of a document, a digital signature also proves the ownership of the private key corresponding to the public key. Only the owner of the corresponding private key could have signed the document whose validity was determined by the public key you have. This is an extremely important point.

Symmetric Encryption

This is a simple form of encryption, using a single key. The same key that is used for encrypting the data can also be used for decrypting the data.

Symmetric encryption is faster than asymmetric encryption for two major reasons:

It uses much shorter keys (128 or 256-bit keys are common) than asymmetric encryption (where 1024 and 2048-bit are common key lengths)
It uses simpler mathematical operations like multiplication or XOR in the process of encryption whereas asymmetric encryption uses complex operations like power and modulus.

X.509 Certificate

An X.509 Certificate is a certificate used to prove ownership of a public key. It contains a bunch of information about the entity to which it was issued (including the entity’s public key). The certificate also includes a digital signature signed by the private key of a Certificate Authority (CA) who verified that the information provided is indeed correct. SSL Certificates are essentially X.509 certificates.

The SSL/TLS Handshake

Having understood the key terms, let us now focus on what happens when you make an HTTPS request. When you type in https://iotespresso.com in your browser (say Google Chrome), how does it show the lock symbol beside the URL?

Here’s the answer:

The client (your browser) sends a hello request to the server (the machine hosting the HTML files corresponding to iotespresso.com) with which it is trying to communicate. In this hello message, it sends
- the TLS versions it supports,
- the encryption algorithms (cipher suites) it supports,
- a string of random bytes (client random)
The server responds with the following:
- Its SSL certificate,
- The chosen cipher suite
- a string of random bytes (server random)
The client validates the SSL certificate of the server (this is perhaps the most interesting part, and covered in detail in the next section)
After having validated that the server is indeed who it says it is, the client uses the server’s public key (obtained from its SSL certificate) and uses it to encrypt another string of random bytes (premaster secret). Only the server’s private key can decrypt it. Thus, anyone snooping cannot make any sense of it.
The server decrypts the premaster secret. Now, the server and the client use the client random, the server random, and the premaster secret to arrive at session keys. These keys enable symmetric encryption.
The client sends a ‘finished’ message encrypted with a session key
On receiving this message, the server also sends a ‘finished’ message encrypted with a session key
The handshake is now complete, and the client and the server use the session keys to symmetrically encrypt data for the rest of the communication.

As you can see, steps 4 and 5 constitute asymmetric encryption using the server’s public and private keys. The next steps and the rest of the data exchange, all constitute symmetric encryption (which is faster).

Now, let’s focus on step 3 in detail. How does the client validate the server’s SSL certificate?

SSL Certificate Validation

An SSL certificate, as discussed above, is an X.509 certificate. If, on your browser (using Google Chrome as an example), you click on the lock icon, and then click on the ‘Connection is secure’ option, you will see a ‘Certificate is valid’ text. Click on it. You will see the SSL certificate details. Next, click on the Certification Paths tab. There you will see the CA who verified the SSL certificate of iotespresso.com.

As you can see, the certificate of iotespresso.com was signed by a CA called R3. By using R3’s public key, one can verify that the digital signature on iotespresso.com’s certificate is okay. But, why should Chrome trust R3? Well, because R3’s certificate was, in fact, signed by ISRG Root X1. Again, using its public key, one can verify that the digital signature on R3’s certificate is valid. But why should Chrome trust ISRG Root X1? Because it is one of the trusted Root CAs. Root CAs have self-signed certificates (i.e., their certificate was signed by their own private key). All browsers maintain a list of Root CAs that they trust.

On Google Chrome, you can go to Settings -> Security and Privacy -> Security -> Manage Certificates -> Trusted Root Certification Authorities. You will find ISRG Root X1 in the list, along with several others.

Now you would know why your browser would sometime give you an error saying that your ‘Connection is Not Private’. Either the site doesn’t use SSL, or else the browser wasn’t able to verify the SSL certificate’s signature and trace it back to a trusted root CA.

Other Aspects of HTTPS

While the section above cover how HTTPS works generally, some finer details that you should be aware of:

HTTPS works on port 443, as opposed to port 80 used for HTTP
It is possible (but not recommended) to skip the server SSL validation step (if implementing HTTPS in a resource-constrained environment). Your communication will still be encrypted. The only problem is that you won’t know if the server you are talking it is indeed who it claims to be.

That’s it for this article. I hope you liked it. Thanks for reading.

References

Found this post helpful? Then check out other posts on iotespresso.com.