HTTPS transaction process

by

In this post I am walking through the HTTPS transaction process starting from the ClientHello request until the encryption of real data.

1. TCP Handshake

The client initiates a three-way TCP handshake with the server to establish a reliable communication channel:

  • Client sends SYN: Requests to start communication.
  • Server responds with SYN-ACK: Acknowledges the request.
  • Client sends ACK: Final confirmation.

Once the TCP connection is established, the TLS handshake begins.

2. TLS Handshake Steps

The TLS handshake involves several steps to establish a secure, encrypted connection:

A. ClientHello

The client sends a ClientHello message to the server. This message includes:

  • Supported TLS versions.
  • A randomly generated number (Client Random).
  • Cipher suites supported by the client.

B. ServerHello

The server responds with a ServerHello message. It contains:

  • The chosen TLS version and cipher suite.
  • Another randomly generated number (Server Random).

C. Server Certificate and Validation

The server sends its digital certificate to the client. A certificate consists of two main sections:

  1. Certificate Data – Includes fields like Subject, Issuer, Validity, Public Key, etc.
  2. Signature Section – Contains:
    • Signature Algorithm (e.g., sha256WithRSAEncryption)
    • Signature (the actual cryptographic signature)

The signature is created as follows:

  1. Hashing: The certificate authority (CA) takes the Certificate Data (such as the public key, owner details, expiration date, etc.) and generates a hash using the Signature Algorithm (e.g., SHA-256).
  2. Encryption (Signing): The CA encrypts this hash using its private key. This encrypted hash is the digital signature.
  3. Appending the Signature: The CA attaches the Signature Section to the certificate and issues it to the website owner.

Verification Process

When a browser receives the certificate, it verifies the signature as follows:

  1. Hash Calculation: The browser extracts the certificate contents (excluding the signature) and computes the hash using the same hash algorithm found in the certificate.
  2. Signature Decryption: The browser uses the CA’s public key (from the CA’s certificate) to decrypt the digital signature, which reveals the original hash.
  3. Comparison: The browser compares the computed hash with the decrypted hash.
    • If they match, the certificate is valid.
    • If they don’t match, the certificate may be tampered with or forged.

D. Key Exchange

There are two common methods:

  1. RSA: The server’s public key encrypts the Pre-Master Secret that the client generates.
  2. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral): Both parties contribute to generating a shared secret without transmitting it.

The result of this key exchange is the Session Key used for encryption.

E. Finished Messages

  • Both client and server compute a cryptographic hash of the entire handshake.
  • They exchange Finished messages encrypted with the session key to confirm the handshake.

3. Secure Data Transmission

After the TLS handshake:

  • All communication between the client and server is encrypted using symmetric encryption (e.g., AES) with the session key.
  • This encryption ensures data confidentiality and integrity.

This process ensures secure, authenticated, and encrypted communication between a client and a server during an HTTPS transaction.

Leave a Comment