Why HTTPS Slows You Down and How It Secures Your Data

Part 1: HTTPS Protocol and Principles

HTTPS can be regarded as HTTP + TLS. HTTP is the familiar clear‑text protocol for web traffic, while TLS (the successor of SSL) provides transport‑layer encryption and was standardized by the IETF after its initial release by Netscape in 1995.

TLS sits between the application layer and the transport layer and is composed of five sub‑protocols: the application data protocol, the handshake protocol, the alert protocol, the change‑cipher‑spec protocol, and the heartbeat protocol. TLS records are transmitted using the Record protocol.

Common HTTP versions are HTTP/1.1, while TLS versions in use include TLS 1.2, TLS 1.1, TLS 1.0 and the insecure SSL 3.0. TLS 1.2 and TLS 1.1 are currently considered safe, whereas TLS 1.0 and SSL 3.0 have known vulnerabilities. TLS 1.3 is an upcoming major revision that promises better security and performance.

HTTPS Functions

HTTPS provides three core capabilities: content encryption (the data exchanged between browser and server is encrypted), identity authentication (the client can verify it is communicating with the legitimate server), and data integrity (preventing tampering of the transmitted content).

HTTPS Principles

1. Content Encryption

Encryption algorithms fall into two categories: symmetric (same key for encryption and decryption) and asymmetric (different public and private keys). Symmetric encryption offers high performance but requires a secure way to share the key; asymmetric encryption solves the key‑exchange problem.

RSA – simple implementation, widely used for both key exchange and certificate signing; requires large prime numbers (commonly 2048 bits) and is CPU‑intensive.

DH (Diffie‑Hellman) – early key‑exchange algorithm, also CPU‑heavy.

ECDHE – elliptic‑curve Diffie‑Hellman, uses smaller keys (e.g., 256 bits) for comparable security, supports forward secrecy and false start.

ECDH – elliptic‑curve DH without forward secrecy.

DHE – DH with temporary keys, very CPU‑intensive.

In practice, RSA and ECDHE (often ECDHE_RSA) are recommended because RSA is universally supported and ECDHE offers better performance and forward secrecy.

RSA key‑exchange steps:
1. Randomly pick two primes p, q (e.g., p=13, q=19) → n = p·q.
2. Compute φ(n) = (p‑1)(q‑1) and choose e such that 1<e<φ(n) and gcd(e,φ(n))=1 (e.g., e=17).
3. Compute d, the modular inverse of e modulo φ(n) (e·d ≡ 1 mod φ(n)).
4. Public key = (n, e), private key = (n, d).
5. Encrypt premaster_secret with the public key; server decrypts with the private key.

2. Asymmetric Key Exchange

RSA key exchange encrypts the premaster secret with the server’s public key. ECDHE first performs an elliptic‑curve DH exchange to derive a shared secret, then signs the exchange with the server’s private key for authentication.

3. Symmetric Content Encryption

After key exchange, a symmetric cipher encrypts the actual application data. Stream ciphers (e.g., RC4, now deprecated) and block ciphers (e.g., AES‑CBC, now discouraged; AES‑GCM is recommended despite higher CPU cost) are used. ChaCha20 is a modern, fast stream cipher adopted by Google.

2. Identity Authentication

Authentication relies on PKI and digital certificates. A typical certificate chain includes the end‑entity, a Registration Authority (RA), a Certificate Authority (CA), a CRL issuer, and a repository. The certificate contains the public key, validity period, and signature from the CA.

Digital signatures are created by hashing the certificate data and encrypting the hash with the CA’s private key; verification uses the CA’s public key.

3. Data Integrity

Integrity checks use hash‑based MACs such as MD5 (now discouraged) or SHA families. SHA‑1 is considered broken; modern deployments use SHA‑256 or stronger algorithms.

Part 2: HTTPS Performance Impact

HTTPS adds latency in two main ways: extra network round‑trip times (RTTs) during the TLS handshake and additional CPU time for cryptographic operations.

The full HTTPS handshake can require up to seven extra RTTs: initial TCP three‑way handshake, HTTP 302 redirect to HTTPS, second TCP handshake, TLS handshake (client‑hello, server‑hello, certificate exchange, key exchange, etc.), DNS lookup for the CA, TCP handshake to the CA, OCSP/CRL validation, and the final handshake round. In practice, most connections benefit from session resumption and cached DNS, reducing the overhead.

CPU overhead comes from RSA signature verification, RSA/ECDHE key exchange, symmetric encryption/decryption, and integrity checks on both client and server. Typical additional latency is 10‑50 ms on PCs and 50 ms or more on mobile devices; servers see a few milliseconds extra due to private‑key operations.

HTTPS is essential for protecting user privacy and preventing traffic hijacking, but it does introduce measurable performance costs that can be mitigated through optimization, caching, and the use of modern cipher suites.