HTTPS transaction process

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.