Symmetric Encryption, Public-Key Crypto, and Certificates in HTTPS
Keys
Plaintext is the original message; ciphertext is the encrypted result.
In the simplest scheme you feed plaintext into an encryption function to get ciphertext. If someone steals that function, they can decrypt everything, and replacing the function is costly. To improve security we add a second argument—a secret shared by the communicating parties. Without the key you cannot properly decrypt the message. The algorithm stays public; only the key must remain secret, and rotating it is easy.
Symmetric encryption
Symmetric algorithms use the same key for encryption and decryption.
Popular choices:
- DES
- Triple-DES
- RC2
- RC4
Symmetric keys must be shared. On the internet every pair of parties needs its own key. With N participants you would need N * (N - 1) keys.
Public-key encryption
To avoid key-distribution headaches, public-key (asymmetric) cryptography uses different keys for encryption and decryption. One key becomes public and anyone can use it to encrypt data, but only the holder of the private key can decrypt it. This solves the sharing problem.
Security requires that the private key cannot be derived even if you know:
- the public key;
- a ciphertext;
- a plaintext along with its ciphertext.
Common algorithms:
- RSA
- DH
- ECDHE
- ECDH
- DHE
Public-key crypto is computationally expensive, so HTTPS uses a hybrid: exchange a symmetric key with public-key crypto, then use the symmetric key for bulk data.
Digital signatures
Encryption can also prove authenticity. A digital signature attaches a cryptographic checksum to a message. Only the sender can produce the signature (because it uses the private key), and anyone with the public key can verify that the message was not tampered with.
Typically the sender hashes the message, signs the digest with a private-key operation, and sends both the message and signature. The receiver hashes the message and verifies the signature with the public key. If they match, the message is authentic.
RSA supports both encryption and signing: treat the decrypt function D as the signing primitive and the encrypt function E as verification.
Certificates
Public-key crypto alone does not identify the sender. Anyone can generate a key pair and claim to be example.com. Preloading every site’s public key is impractical, and safely distributing them is harder. Certificates bridge that gap.
A certificate is a digital ID card containing:
- Format version
- Serial number
- Signature algorithm
- Issuer
- Validity period
- Subject name
- Subject public key
- Issuer’s digital signature
The signature covers every other field. Although anyone can mint a certificate, browsers only trust those signed by recognized Certificate Authorities (CAs).
How browsers verify certificates
CAs issue certificate chains. The leaf certificate belongs to the site; intermediate certificates sit in the middle; the root certificate appears in the browser’s trust store. Verification walks up the chain, checking signatures and validity along the way. (This section draws from multiple references to clarify the full flow.)
Certificate status
Browsers also check whether a certificate has been revoked, typically via CRL or OCSP.
SSL/TLS layer
HTTPS stacks TLS beneath HTTP:
- Application: HTTP
- Security: SSL/TLS
- Transport: TCP
- Network: IP
- Link: Ethernet, Wi‑Fi, etc.
OpenSSL is the most widely used TLS implementation.
HTTPS handshake
(Based on SSL/TLS协商流程概述.)
ClientHello
The client proposes:
- protocol version (e.g., TLS 1.0)
- a random value for key derivation
- supported cipher suites
- supported compression methods
ServerHello
The server responds with:
- the negotiated protocol version
- its random value
- the chosen cipher suite
- the server certificate
If mutual TLS is required the server also requests a client certificate.
Client response
The client validates the certificate:
- Is it signed by a trusted CA?
- Does the subject match the requested hostname?
- Is it within the validity period?
If all checks pass, the client sends:
- a randomly generated pre-master secret encrypted with the server’s public key
- a “change cipher spec” message indicating that subsequent traffic is encrypted
- a “finished” message containing a hash of the handshake so far
Both sides now derive the shared session key from the three random values.
Server response
The server computes the session key, then replies with:
- its own “change cipher spec”
- a “finished” message that hashes the prior handshake data
The TLS handshake completes, and the parties exchange HTTP data encrypted with the session key.
References: