Understanding the Principles Behind HTTPS

Background

Browsers display a lock icon in the address bar to indicate that the session is protected by HTTPS.

HTTPS Overview

HTTPS is essentially HTTP + SSL/TLS. HTTP alone transmits messages in clear text, which can be eavesdropped; SSL/TLS adds encryption and authentication.

TLS Handshake

After the TCP three‑way handshake establishes a TCP connection, the TLS handshake proceeds as follows:

Client Hello: the client sends a “hello” message containing supported TLS versions and cipher suites.

Server Hello: the server selects the best TLS version and cipher suite, sends its certificate (which contains the server’s public key), and optionally a Server Key Exchange.

Certificate Verification: the client validates the server’s certificate.

Pre‑Master Secret: the client generates a random pre‑master secret, encrypts it with the server’s public key, and sends it to the server.

Decryption of Pre‑Master Secret: the server uses its private key to decrypt the pre‑master secret.

Session Key Derivation: both parties derive the same symmetric session key from the pre‑master secret.

Application Data Encryption: subsequent HTTP messages are encrypted with the symmetric session key.

Symmetric vs. Asymmetric Encryption

Asymmetric encryption (public‑key cryptography) is used only to exchange the session key securely; the actual data transfer uses fast symmetric encryption, which offers low overhead and high performance.

Why Certificates?

Without a trusted certificate, an attacker could replace the server’s public key with their own and perform a man‑in‑the‑middle attack. The following diagram shows such an attack:

Certificates bind a public key to a verified identity, preventing the above attack.

Certificate Anatomy

An X.509 certificate (the standard format for TLS certificates) can be inspected with openssl:

openssl s_client -showcerts -connect google.com:443

The output includes fields such as Issuer, Subject, Subject Public Key Info, and Signature Algorithm (e.g., sha256WithRSAEncryption).

Issuer: the CA that issued the certificate.

Subject: the entity the certificate represents (e.g., CN = *.google.com).

Subject Public Key Info: the server’s public key.

Signature Algorithm: the hash and encryption algorithm used to sign the certificate.

Digital Signatures

Signing a message involves hashing the message and encrypting the hash with the signer’s private key; verification decrypts the signature with the public key and compares hashes. This provides:

Message integrity – the content has not been altered.

Source authentication – the signer possesses the private key.

Hash Functions

Hashes are one‑way functions that map arbitrary data to a fixed‑size digest (e.g., SHA‑256). They are collision‑resistant, meaning two different inputs should not produce the same digest.

Private Key Identity

Only the holder of the private key can produce a valid signature that the corresponding public key can verify, establishing identity.

Certificate Chain

Servers usually send a chain of certificates: the server certificate, one or more intermediate CA certificates, and a root CA certificate. Each certificate’s Issuer matches the Subject of the next certificate up the chain.

Manual Verification of an SSL/TLS Certificate

Below is a step‑by‑step OpenSSL workflow to verify a certificate manually.

Extract the intermediate CA’s public key:

openssl x509 -in ./intermediate_ca.pem -noout -pubkey > ./intermediate_ca_pub.pem

Extract the server certificate’s digital signature (binary):

openssl x509 -in ./google_com.pem -text -noout -certopt ca_default,no_validity,no_serial,no_subject,no_extensions,no_signame \

| grep -v 'Signature Algorithm' \

| tr -d '[:space:]' \

| xxd -r -p > ./certificate-signature.bin

Decrypt the signature with the intermediate CA’s public key:

openssl rsautl -verify -inkey ./intermediate_ca_pub.pem -in ./certificate-signature.bin -pubin > ./certificate-signature-decrypted.bin

Parse the decrypted signature to obtain the hash:

openssl asn1parse -inform der -in ./certificate-signature-decrypted.bin

Re‑calculate the hash of the certificate body (excluding the signature):

openssl asn1parse -i -in ./google_com.pem -strparse 4 -out ./google_com_cert_body.bin -noout

openssl dgst -sha256 ./google_com_cert_body.bin

If the recomputed SHA‑256 digest matches the hash extracted from the signature, the intermediate CA indeed signed the server certificate.