Understanding HTTPS: Why It Combines Symmetric and Asymmetric Encryption

1. Two Encryption Mechanisms in HTTPS

Symmetric encryption : the same key encrypts and decrypts data, offering very high speed and suitability for large‑volume data transfer. Its fatal drawback is that the key cannot be safely transmitted, so it is used only for the payload, never for key exchange.

Asymmetric encryption : uses a public‑key/private‑key pair. The public key encrypts data, and only the corresponding private key can decrypt it. This provides strong security for key exchange but is computationally heavy and unsuitable for bulk data.

Optimal combination : transmit the symmetric key with asymmetric encryption, then use the symmetric key for the actual data. This achieves both "absolute security" and "high‑speed transmission"—the core of HTTPS.

2. TLS Handshake Overview (Six Steps)

① Client Hello

The client (browser or app) initiates the connection, sending three pieces of information: supported TLS version, list of supported cipher suites, and a random number (Random A) for later key generation.

② Server Hello

The server replies with four items: the selected TLS version, the chosen cipher suite, a random number (Random B), and the server’s certificate containing the public key, domain name, and validity period.

③ Certificate Verification

The client validates the certificate against several criteria—issued by a trusted CA, domain match, not expired, and signature intact—to prevent man‑in‑the‑middle attacks. Failure aborts the connection.

④ Client Sends Encrypted Pre‑Master Secret

The client generates a random pre‑master secret, encrypts it with the server’s public key, and sends it. The transmission remains encrypted even if intercepted.

⑤ Both Parties Derive the Same Symmetric Key

Using Random A, Random B, and the pre‑master secret, both client and server independently compute an identical final symmetric key, completing key exchange without exposing any plaintext.

⑥ Encrypted Application Data Transfer

All subsequent HTTP requests and responses are encrypted with the derived symmetric key. Any tampering causes verification failure and data is discarded.

3. Common HTTPS Issues and Solutions

Certificate expiration : browsers show security warnings and API calls fail. Solution : renew certificates 1–2 months before expiry and enable automatic renewal; always verify validity before deployment.

Domain mismatch : the certificate’s domain does not match the accessed domain. Solution : obtain wildcard or multi‑domain certificates and ensure strict domain alignment.

Local packet capture breaking HTTPS : interception tools act as a man‑in‑the‑middle and need a trusted root certificate to decrypt traffic. Solution : install the tool’s CA certificate only in test environments; never in production.

HTTPS perceived as slower than HTTP : the only overhead is the initial handshake, which is negligible. With TLS 1.3 session resumption, performance is essentially equal to HTTP, making full‑site HTTPS mandatory in production.

4. Key Takeaways for Beginners

HTTPS = HTTP + TLS encryption layer, eliminating eavesdropping, tampering, and spoofing.

Core logic: asymmetric encryption transports the symmetric key; symmetric encryption transports the data.

Certificate validation is the security cornerstone that blocks man‑in‑the‑middle attacks.

Production environments must enforce HTTPS with valid CA‑issued certificates; plain HTTP is unacceptable.