Detailed Explanation of HTTPS and SSL/TLS Handshake Process

Detailed Explanation of HTTPS and SSL/TLS Handshake Process

Knowledge Point Description
HTTPS is a secure communication protocol built upon the HTTP protocol by adding an SSL/TLS encryption layer. It is used to ensure the confidentiality and integrity of data transmission. Its core lies in the SSL/TLS handshake process, which negotiates a symmetric key through asymmetric encryption and ultimately uses symmetric encryption for efficient data transmission.

I. Basic Concepts of HTTPS

  1. Security Flaws of HTTP

    • Plaintext Transmission: Request and response content can be eavesdropped on by a man-in-the-middle.
    • Inability to Verify Identity: May access a forged server.
    • Data Easily Tampered With: A man-in-the-middle can modify transmission content.

  2. HTTPS Solutions

    • Encrypted Transmission: Prevents eavesdropping through a hybrid encryption mechanism.
    • Identity Authentication: Verifies server identity through digital certificates.
    • Integrity Verification: Prevents tampering through MAC (Message Authentication Code).

II. Step-by-Step Analysis of SSL/TLS Handshake
Taking TLS 1.2 as an example, a complete handshake involves the following steps:

  1. ClientHello

    • Client Sends:
      • Supported TLS version (e.g., TLS 1.2)
      • Client Random (used for subsequent key generation)
      • List of supported cipher suites (e.g., RSA, ECDHE)
      • Session ID (used for session resumption)

  2. ServerHello

    • Server Responds:
      • Selected TLS version and cipher suite
      • Server Random
      • Session ID (a new ID is generated for a new session)

  3. Server Certificate Transmission

    • Server sends the digital certificate chain to the client.
    • The certificate contains server public key, domain name, issuing authority (CA), etc.
    • Optionally requests client certificate (for mutual authentication scenarios).

  4. ServerKeyExchange

    • Depending on the cipher suite type, may send:
      • DH Parameters: Server ephemeral public key (for algorithms like ECDHE)
      • Signature: Signs parameters with the server's private key (to prevent tampering).

  5. ServerHello Done

    • Server informs the client that the initial negotiation messages are complete.

  6. Client Verifies Certificate

    • Client verifies the certificate chain:
      1. Checks certificate validity period.
      2. Verifies if the issuing authority is trusted (queries system trust store).
      3. Confirms the domain name in the certificate matches the accessed domain name.
      4. Verifies digital signatures to ensure the certificate hasn't been tampered with.

  7. ClientKeyExchange

    • Client generates a Pre-Master Secret.
    • Encrypts the Pre-Master Secret with the server's public key and sends it to the server.
    • (In ECDHE scheme) The client also sends its ephemeral public key parameters.

  8. Key Generation

    • Both parties generate symmetric session keys based on:
      • Client Random
      • Server Random
      • Pre-Master Secret
    • Generated via a PRF (Pseudo-Random Function):
      • Encryption key (for data encryption)
      • MAC key (for integrity verification)
      • Initialization Vector (IV, for block cipher modes)

  9. Switch to Encrypted Communication

    • Both parties send ChangeCipherSpec messages, confirming that subsequent communication will use the negotiated keys.
    • Exchange Finished messages (encrypted handshake summary) to verify that the handshake process hasn't been tampered with.

III. Abbreviated Handshake (Session Resumption)
When the client possesses a Session ID or session ticket:

  1. Client includes the Session ID in the ClientHello.
  2. Server confirms the session is valid and skips certificate verification and key exchange.
  3. Uses the previously negotiated session key to quickly resume communication.

IV. Defense Against Related Attacks

  1. Downgrade Attacks: Prevented from negotiating weak encryption algorithms via TLS extensions.
  2. Replay Attacks: Ensure message freshness using random numbers and timestamps.
  3. Man-in-the-Middle Attacks: The certificate system guarantees the authenticity of the server's public key.

Core Summary
HTTPS achieves a balance between security and performance through a hybrid mechanism of "asymmetric encryption for key negotiation + symmetric encryption for data transmission." The core objective of the handshake process is to securely negotiate a session key known only to the communicating parties and to implement identity authentication through digital certificates.