HTTPS Encryption Principles and Process

HTTPS Encryption Principles and Process

1. Background and Requirements
The HTTP protocol transmits data in plaintext, making it vulnerable to eavesdropping, tampering, or impersonation. HTTPS (HTTP Secure) addresses these issues through encryption technologies, ensuring data confidentiality (encryption), integrity (tamper-proof), and authentication (impersonation prevention).

2. Core Encryption Technology Combination
HTTPS is not a single technology but a combination of three types:

  • Symmetric Encryption: Uses the same key for encryption and decryption, highly efficient, but key transmission is insecure.
  • Asymmetric Encryption: Uses a public-private key pair; data encrypted with the public key can only be decrypted by the private key, and vice versa. High security but computationally complex.
  • Hash Functions and Digital Signatures: Verify data integrity (e.g., SHA-256) and authenticate identity through digital signatures.

Key Issue: If asymmetric encryption is used directly for data transmission, efficiency is too low; if only symmetric encryption is used, key exchange is insecure. HTTPS's solution is hybrid encryption.

3. HTTPS Connection Establishment Process (TLS Handshake)
The following uses RSA key exchange as an example (ECDHE is more commonly used in practice):

Step 1: Client Initiates Request (ClientHello)

  • The client sends to the server:
    • Supported TLS version (e.g., TLS 1.2).
    • List of supported cipher suites (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
    • A random number (Client Random).

Step 2: Server Response (ServerHello)

  • The server returns:
    • Selected TLS version and cipher suite.
    • Another random number (Server Random).
    • Digital Certificate (contains public key, domain name, issuing authority, etc.).

Step 3: Client Verifies Certificate

  • The client uses pre-installed CA root certificates to verify the legitimacy of the server's certificate (e.g., whether the signature is valid, if the domain name matches, if it is expired).
  • If verification fails, a risk warning is displayed (e.g., a browser warning).

Step 4: Key Exchange and Pre-Master Secret Generation

  • The client generates a third random number, Pre-Master Secret, encrypts it with the server's public key, and sends it to the server.
  • The server uses its private key to decrypt and obtain the Pre-Master Secret.

Step 5: Session Key Generation

  • Both client and server use Client Random, Server Random, Pre-Master Secret to generate a Master Secret through the same algorithm, from which a symmetric encryption key (Session Key) is derived.
  • All subsequent communications are encrypted using this symmetric key, balancing security and efficiency.

Step 6: Handshake Finalization Verification

  • Both parties exchange Finished messages (encrypted with the Session Key) to verify that the handshake process was not tampered with.

4. Key Design Principles

  • Forward Secrecy: When using ECDHE key exchange, the Pre-Master Secret for each session is independent. Even if the server's private key is compromised, past sessions cannot be decrypted.
  • Digital Certificate Chain: Hierarchical verification through trusted root CAs (e.g., Let's Encrypt, DigiCert) prevents man-in-the-middle attacks.
  • Session Resumption: Reduces redundant handshake overhead via Session ID or Session Ticket.

5. Practical Application Example
When a browser visits https://example.com:

  1. The address bar displays a lock icon, indicating the connection is encrypted.
  2. Certificate details and encryption protocols can be viewed in the Security tab of developer tools.

Summary: HTTPS uses asymmetric encryption to authenticate identity and securely exchange keys, then switches to symmetric encryption for efficient data transmission, achieving a balance between security and performance.