HTTPS

Before diving into how HTTPS works, it's essential to understand some fundamental concepts like symmetric and asymmetric encryption.

Symmetric Encryption​

Symmetric encryption is a cryptographic technique where the same key is used for both encryption and decryption of data.

Example: Tom and Bob are detectives. Tom wants to send a secret message to Bob, such as "Meet at 7pm near Harbour." To keep the message secure, Tom encrypts it using a shared key (using algorithms like AES, DES, or 3DES). The encrypted message is sent to Bob, who can decrypt it using the same key.

Asymmetric Encryption​

Asymmetric encryption, also known as public-key encryption, is a cryptographic technique that uses pairs of keys to encrypt and decrypt data. It utilizes two separate keys: a public key and a private key.

How it Works​

• Public Key: The server generates a pair of keys—a public key and a private key. The public key is made available to anyone who wants to send encrypted messages to the server. It can be freely shared and distributed.

• Private Key: The private key is kept secret and known only to the server. It is used to decrypt messages that have been encrypted with the corresponding public key.

• Encryption: To send a secure message to a server, a client encrypts the message using the server's public key. Only the server with the corresponding private key can decrypt and read the message.

• Decryption: The server uses its private key to decrypt the received message and recover the original plaintext.

• Digital Signatures: Asymmetric encryption is also used for digital signatures, where the sender signs a message using their private key. The recipient verifies the signature using the sender's public key, providing authentication and ensuring the integrity of the message.

Certificate Authority (CA)​

Why Do We Need a CA?​

Imagine you want to log in to a website. Here’s how a Certificate Authority helps ensure security:

• Scenario 1: A legitimate server sends its public key to the client. The client can then encrypt sensitive data (like login credentials) using this public key, ensuring that only the server can decrypt it using its corresponding private key.

• Scenario 2: A hacker intercepts the connection and sends their public key instead. If the client encrypts data using this key, the hacker can decrypt it with their private key, potentially stealing sensitive information.

To prevent this, Certificate Authorities come into play. A CA acts as a trusted third party, verifying the legitimacy of a server’s public key by issuing a digital certificate. This certificate assures clients that they are communicating with the intended server, not a hacker.

What Does a Certificate Contain?​

1. Issued to: The server to which the certificate is issued.

2. Issued by: A trusted Certificate Authority. There are currently 12 major CAs, and their root certificates are preloaded in clients (browsers or operating systems). On a Mac, you can find these under Keychain Access.

3. Public Key: The public key of the server. Remember, this key is specific to the server (while the CA has its own public and private key pair).

4. Digital Signature: Created by hashing the certificate’s contents (except the signature) using a hashing algorithm, then encrypting this hash with the CA's private key. Only the CA's public key can decrypt and verify this signature, ensuring authenticity.

How HTTPS Works​

1. TCP Connection Establishment​

A 3-way handshake is done between the client and server to establish a TCP connection. We will explore the TCP handshake in detail later.

2. TLS Handshake​

• ClientHello: The client initiates the handshake by sending a ClientHello message, which includes supported SSL/TLS versions and cipher suites (encryption algorithms).

• ServerHello: The server responds with a ServerHello message, selecting the SSL/TLS version and cipher suite.

• Certificate Exchange: The server sends its digital certificate to the client. A hacker cannot impersonate this by sending a fake certificate, as their certificate wouldn’t be signed by a trusted CA.

• Certificate Verification: The client decrypts the digital signature on the certificate using the CA’s public key (preloaded on the client’s system). It then hashes the certificate content to verify its integrity. If the hashes match, the connection proceeds; otherwise, it is terminated, and a security warning is displayed.

• Session Key Exchange: To enhance speed, symmetric encryption is used for data transmission. The client creates a session key, encrypts it with the server’s public key (from the certificate), and sends it to the server. The server decrypts it using its private key. Now, both the client and server use this session key for secure, symmetric encryption of data.

• Finished Messages: Both client and server send a “Finished” message, encrypted with the session key, containing a hash of the entire handshake process.

3. HTTP Request/Response​

Once the TLS handshake is complete, the client and server exchange HTTP requests and responses over the secure TLS connection. This covers all types of data, such as HTML pages, images, and other content.

4. TLS Closure​

To end the secure connection, both parties send a close_notify alert, signaling the termination of the TLS session.

5. TCP Connection Termination​

After the TLS session ends, the underlying TCP connection is closed gracefully using TCP FIN packets and acknowledgments.

Chain of Trust​

While what we've covered so far ensures security, the Chain of Trust adds another layer of protection and scalability. It involves using multiple certificates (like root, intermediate, and server certificates) rather than relying on a single certificate.

Advantages of Chain of Trust​

1. Scalability: Instead of one Root CA managing all certificates, Intermediate CAs can issue certificates under the Root CA, making it easier to manage and distribute certificates globally.

2. Security: If a Root CA’s private key is compromised, all certificates would need to be revoked, causing massive disruptions. However, if only an Intermediate CA's private key is compromised, only its certificates are affected, minimizing the impact.

How the Chain of Trust Works​

• In the HTTPS process, the server sends two certificates: the server certificate and the intermediate certificate.

• The client has the root certificate's public key preloaded, which can be used to verify the signature of the Intermediate CA.

• Using the verified Intermediate CA's public key, the client can verify the server's certificate signature.

• This process ultimately verifies the server's public key, allowing secure communication to proceed.