Why HTTPS Matters: Encryption, Certificates, and Handshake Explained

Why HTTPS Is Needed

HTTPS (Hypertext Transfer Protocol Secure) is the secure version of HTTP. It protects confidential data such as bank cards or ID numbers from eavesdropping, tampering, and impersonation during transmission.

Confidentiality cannot be guaranteed with HTTP.

Integrity and accuracy of messages are not ensured.

The source of messages cannot be reliably verified.

HTTPS was created to solve these three problems.

Basic Concepts

HTTPS uses encryption, digital certificates, and digital signatures to secure communication.

Symmetric and Asymmetric Encryption

Two main encryption methods are used:

Symmetric encryption : client and server share a secret key to encrypt and decrypt messages. It ensures confidentiality but the shared key is vulnerable to leakage.

Asymmetric encryption : each side has a public key and a private key. The public key can be shared openly, while the private key remains secret. This solves the key‑leakage issue and also provides authenticity.

Symmetric encryption is fast but insecure if the key is exposed; asymmetric encryption is more secure but slower, so HTTPS combines both.

Digital Certificates and Signatures

Certificates are issued by Certificate Authorities (CAs). The process:

Generate a key pair locally.

Submit the public key and organization info to a CA.

The CA creates a hash (digest) of the information.

The CA encrypts the digest with its private key, producing a digital signature.

The CA bundles the signature, the public key, and the submitted information into a digital certificate and returns it.

When a server presents its certificate, the client uses the CA’s public key (built‑in root certificates) to verify the signature and extract the server’s public key. The client also hashes the received information and compares it to the decrypted digest to ensure integrity.

HTTPS Principle

HTTPS does not introduce a new protocol; it wraps HTTP with an encryption layer called SSL/TLS, integrating symmetric encryption, asymmetric encryption, certificates, and signatures to achieve both performance and security.

HTTPS Handshake Process

The SSL/TLS handshake consists of six phases and twelve steps:

Client sends Client Hello with supported TLS version and cipher suites.

Server replies with Server Hello selecting version and cipher suite.

Server sends its certificate.

Server sends Server Hello Done.

Client sends Client Key Exchange containing a pre‑master secret encrypted with the server’s public key.

Client sends Change Cipher Spec to switch to the negotiated cipher.

Client sends Finished with a verification hash.

Server sends Change Cipher Spec.

Server sends Finished.

Both sides now have a secure channel and can exchange HTTP data.

Application layer communication (HTTP requests/responses) occurs.

Client closes the connection with a close_notify alert, followed by TCP FIN.

During data transfer, a MAC (Message Authentication Code) is added to each message to ensure integrity.

When to Use HTTPS

HTTPS is essential for high‑security scenarios such as banking or e‑commerce, but it incurs computational overhead and requires paid certificates. For low‑risk personal sites, HTTP may be sufficient.