How does HTTPS actually work?

Reading Time: 5 minutes

What is HTTPS?

We’ve heard a lot about HTTPS, and we use it every day. If you access a website from your browser and you see a little green padlock and the letters “https” in your address bar then congratulations, you are accessing this safely via HTTPS.

HTTPS is a combination of HTTP Protocol and an SSL/TLS encryption layer. When the server uses HTTPS, unless they make any mistake during setup, a 3rd party will not intercept and decrypt the data sent between client and server.

In this post, I will explain to you in detail how HTTPS works and the importance of the SSL handshake. I also referred to Rob Heaton’s blog, this is really an informative article to read.

I assume you know about HTTP Protocol before reading this post. If not, you should read RFC2616 before.

About SSL / TLS, it is a cryptographic protocol that provides communications security over a computer network. SSL standing for Secure Socket Layer was invented by Netscape. According to Wikipedia, version 1.0 was never publicly released; version 2.0 released in February 1995 “contained a number of security flaws which ultimately led to the design of SSL version 3.0”. SSL version 3.0 of 1996 represented a complete redesign of the protocol.

Soon after, the Internet Engineering Task Force (IETF) began to develop a standard protocol that provided the same functionality. They used SSL 3.0 as the basis for that work, which became the TLS (Transport Layer Security) protocol.

The SSL/TLS layer has 2 main purposes:

• To verify that you are talking directly to the server that you think you are talking to
• To ensure that only the server can read what you send it and only you can read what it sends back

How an SSL connection is established?

After establishing TCP Handshake and before sending/receiving a HTTP Request, HTTPS also sets up a “negotiation” between the client and server via SSL/TLS protocol called SSL/TLS Handshake, which differentiates it from HTTP. The goals here are:

• To ensure that client is talking to the right server
• For the parties to have an agreed-upon “cipher suite” including which encryption algorithm they will use to exchange data
• For the parties to have agreed-upon keys necessary for this algorithm

To make it clearer, I use openssl to connect to google.com

openssl s_client -tls1_2 -connect google.com:443

And use Wireshark to capture and filter it
ssl.handshake

The screenshot above shows all frames during the handshake, it can be divided into 3 main phases

1. Hello

This phase includes frames no. 142 and no. 144 .

First of all, Client send Server a message called Client Hello which contains following information:

• SSL/TLS version that Client wants to use in the handshake
• Some random bytes generated by Client that, afterwards, will be used to generate a master key for encryption.
• A list of encryption algorithms called cipher_suites that Client supports.
• A list of compression algorithms that Client supports.
  0 And a list of Extensions. These extensions are not required, but if the server understands, they will be used.

The server responds with a Server Hello, which contains similar information required by the client, including:

• Some random bytes generated by the server that, afterwards, will be used to generate a master key for encryption
• The cipher suite selected by the server (from the previous list sent by the client) that will be used for authentication, encryption and verification of the messages
• The compression algorithm selected by the server (again from the previous list sent by the client) that will be used for compressing each message
• If a extension is accepted by the server, it will notify Client in the Extension tag

2. Certificate Exchange

When the client and server have finished greeting, the server must prove to the client that it is the one Client wants to talk to. This can be done using SSL Certificate.

An SSL certificate contains various pieces of data, including the name of the owner, the property (eg. domain) it is attached to, the certificate’s public key, the digital signature and the certificate’s expiry date.

The client can implicitly trusts the certificate, or check if it is verified and trusted by one of several Certificate Authorities (CAs). Please be noted that for some particular applications, the server, in turn, can require a certificate to verify the client’s identity.

3. Key Exchange

This is the most exciting phase of the handshake. The purpose of this phase is for both parties to agree on a private key. This key is encrypted by asymmetric algorithm (e.g RSA, Diffie Hellman) with the server’s public/private keys. Then it will be used in another symmetric algorithm to encrypt data sent between the client and the server. Both symmetric and asymmetric algorithms have already been agreed on during the Hello phase.

In detail:

• Client generates some random bytes called PreMaster Secret, encrypts this using asymmetric algorithm with public keys (found on its SSL Certificate) and sends to the server.
• Server decrypts ciphertext by private keys and gets PreMaster Secret
• Both client and server use PreMaster Secret to generate Master Secret and Session Key. Master Secret is a shared key to encrypt data sent between the client and server. This process is called Client Key Exchange.

In case Client does not have enough data to generate PreMaster, Server must take the additional step called Server Key Exchange before sending the missing data to the client.

When two parties have a agreed on a shared key, Client notifies Server that it’s time to encrypt communication by sending a Change Cipher Spec Message. This is the final message can be read as plain text before encryption.

Finally Client and Server each sends Encrypted Handshake Message to test. Handshake process ends.

Cipher Suites

In Hello Phase, we can see that Client and Server agree on a Cipher Suite. So, what is this?

Cipher Suite is a list of algorithms which Client and Server use during the handshake and data transmission. There are 4 algorithms:

• Key Exchange algorithm: The asymmetric encryption algorithm to encrypt and decrypt shared key. E.g RSA, DH, ECDH, ECDHE
• Authentication algorithm: The encryption algorithm to authenticate server or client. E.g RSA, DSA, ECDSA
• Bulk cipher algorithm: The symmetric encryption algorithm to encrypt and decrypt data sent between Client and Server. E.g AES, 3DES, CAMELLIA
• Message Authentication Code algorithm: The hash algorithm. E.g SHA, MD5.

Example: We have Cipher Suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
Where:

• TLS is the protocol
• ECDHE is Key Exchange algorithm
• ECDSA is Authentication algorithm
• AES_128_GCM is Bulk cipher algorithm
• SHA256 is Message Authentication Code algorithm