HTTP vs HTTPS - TLS Handshake & Certificate Chain

▶

Steps

setup

Client sends ClientHello

The client initiates the TLS handshake by sending a ClientHello message to the server. This message includes supported TLS versions, cipher suites, and a random nonce.

💡 This step starts the secure connection setup, signaling the client's capabilities and intent to establish a secure session.

Line:

send(ClientHello)

💡 The handshake begins with the client proposing security parameters.

fill_row

Server receives ClientHello and sends ServerHello

The server receives the ClientHello and responds with a ServerHello message. It selects the TLS version and cipher suite from the client's list and sends its own random nonce.

💡 The server confirms the security parameters to use, establishing the basis for the secure session.

Line:

receive(ClientHello)
send(ServerHello)

💡 ServerHello finalizes the protocol parameters for the session.

fill_cells

Server sends Certificate

The server sends its digital certificate to the client. This certificate contains the server's public key and is signed by a trusted Certificate Authority (CA).

💡 The certificate allows the client to verify the server's identity and establish trust.

Line:

send(Certificate)

💡 Certificate transmission is essential for authentication in HTTPS.

fill_cells

Server sends ServerHelloDone

The server sends a ServerHelloDone message indicating it has finished its part of the handshake messages.

💡 This message signals the client to proceed with key exchange and authentication.

Line:

send(ServerHelloDone)

💡 ServerHelloDone marks the transition to client key exchange.

compare

Client verifies Certificate

The client verifies the server's certificate by checking the CA signature and certificate validity.

💡 Verification ensures the server is trustworthy and prevents man-in-the-middle attacks.

Line:

verify_certificate(certificate)

💡 Certificate verification is critical for secure HTTPS connections.

insert

Client sends ClientKeyExchange

The client sends the ClientKeyExchange message containing the pre-master secret encrypted with the server's public key.

💡 This message allows both parties to derive the same session key securely.

Line:

send(ClientKeyExchange)

💡 Key exchange enables encrypted communication.

expand

Client sends ChangeCipherSpec

The client sends a ChangeCipherSpec message to notify the server that subsequent messages will be encrypted using the negotiated keys.

💡 This message signals the switch to encrypted communication.

Line:

send(ChangeCipherSpec)

💡 ChangeCipherSpec marks the start of encrypted data exchange.

insert

Client sends Finished message

The client sends the Finished message encrypted with the session key, containing a hash of all previous handshake messages to verify integrity.

💡 This message confirms the handshake was successful from the client's side.

Line:

send(Finished)

💡 Finished message ensures handshake integrity and authenticity.

expand

Server sends ChangeCipherSpec

The server sends its ChangeCipherSpec message to notify the client that it will also switch to encrypted communication.

💡 This message synchronizes encryption activation on the server side.

Line:

send(ChangeCipherSpec)

💡 Both sides must signal encryption activation.

insert

Server sends Finished message

The server sends its Finished message encrypted with the session key, confirming the handshake integrity from its side.

💡 This final message completes the handshake, allowing secure data exchange to begin.

Line:

send(Finished)

💡 Finished messages confirm both sides agree on the handshake.

reconstruct

Handshake complete, secure connection established

Both client and server have exchanged Finished messages and switched to encrypted communication. The TLS handshake is complete, and secure HTTP (HTTPS) communication can begin.

💡 This final step confirms the secure channel is ready for application data.

Line:

handshake_complete = True

💡 TLS handshake establishes trust and encryption before data transfer.

def tls_handshake():
    # STEP 1
    send(ClientHello())  # Client sends ClientHello
    # STEP 2
    server_hello = receive()
    send(ServerHello(server_hello.selected_version, server_hello.selected_cipher))  # ServerHello
    # STEP 3
    send(Certificate(server_certificate))  # Server sends certificate
    # STEP 4
    send(ServerHelloDone())  # Server signals end of hello messages
    # STEP 5
    verify_certificate(server_certificate)  # Client verifies certificate
    # STEP 6
    send(ClientKeyExchange(encrypt(pre_master_secret, server_public_key)))  # Client sends key exchange
    # STEP 7
    send(ChangeCipherSpec())  # Client switches to encrypted communication
    # STEP 8
    send(Finished(hash_handshake_messages))  # Client sends Finished
    # STEP 9
    send(ChangeCipherSpec())  # Server switches to encrypted communication
    # STEP 10
    send(Finished(hash_handshake_messages))  # Server sends Finished
    # STEP 11
    handshake_complete = True  # Handshake done
    return handshake_complete

📊

HTTP vs HTTPS - TLS Handshake & Certificate Chain - Watch the Algorithm Execute, Step by Step

Watching the TLS handshake step-by-step reveals the sequence and purpose of each message, clarifying how HTTPS secures HTTP communication.

ClientHello sent, handshake started

Hop: 1

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadClientHello: TLS versions, cipher suites, random nonce

🔌 protocolTLS

🚩 flagsClientHello

src→192.168.1.2:52345

dst→93.184.216.34:443

data→TLS versions, cipher suites, random nonce

flags→ClientHello

ClientHello: client→server

ServerHello sent, parameters agreed

Hop: 2

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadServerHello: selected TLS 1.2, AES_256_GCM, random nonce

🔌 protocolTLS

🚩 flagsServerHello

src→93.184.216.34:443

dst→192.168.1.2:52345

data→TLS 1.2, AES_256_GCM, random nonce

flags→ServerHello

ClientHello: client→server

ServerHello: server→client

Certificate sent, client can verify server identity

Hop: 3

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadCertificate: server public key, CA signature

🔌 protocolTLS

🚩 flagsCertificate

src→93.184.216.34:443

dst→192.168.1.2:52345

data→Server public key, CA signature

flags→Certificate

ClientHello: client→server

ServerHello: server→client

Certificate: server→client

ServerHelloDone sent, client to respond

Hop: 4

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadServerHelloDone

🔌 protocolTLS

🚩 flagsServerHelloDone

src→93.184.216.34:443

dst→192.168.1.2:52345

flags→ServerHelloDone

ServerHello: server→client

Certificate: server→client

ServerHelloDone: server→client

Certificate verified successfully

Hop: 5

Client

Server

📦Packet

↗ fromclient

↘ toclient

📄 payloadVerify Certificate

🔌 protocolTLS

🚩 flagsVerify

src→—:—

dst→—:—

data→Certificate verification

flags→Verify

ServerHello: server→client

Certificate: server→client

ServerHelloDone: server→client

ClientKeyExchange sent, key material shared

Hop: 6

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadClientKeyExchange: encrypted pre-master secret

🔌 protocolTLS

🚩 flagsClientKeyExchange

src→192.168.1.2:52345

dst→93.184.216.34:443

data→Encrypted pre-master secret

flags→ClientKeyExchange

Certificate: server→client

ServerHelloDone: server→client

ClientKeyExchange: client→server

Client switched to encrypted communication

Hop: 7

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadChangeCipherSpec

🔌 protocolTLS

🚩 flagsChangeCipherSpec

src→192.168.1.2:52345

dst→93.184.216.34:443

flags→ChangeCipherSpec

ServerHelloDone: server→client

ClientKeyExchange: client→server

ChangeCipherSpec: client→server

Client Finished message sent

Hop: 8

Client

Server

📦Packet

↗ fromclient

↘ toserver

📄 payloadFinished: encrypted handshake hash

🔌 protocolTLS

🚩 flagsFinished

src→192.168.1.2:52345

dst→93.184.216.34:443

data→Encrypted handshake hash

flags→Finished

ClientKeyExchange: client→server

ChangeCipherSpec: client→server

Finished: client→server

Server switched to encrypted communication

Hop: 9

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadChangeCipherSpec

🔌 protocolTLS

🚩 flagsChangeCipherSpec

src→93.184.216.34:443

dst→192.168.1.2:52345

flags→ChangeCipherSpec

ChangeCipherSpec: client→server

Finished: client→server

ChangeCipherSpec: server→client

Server Finished message sent, handshake complete

Hop: 10

Client

Server

📦Packet

↗ fromserver

↘ toclient

📄 payloadFinished: encrypted handshake hash

🔌 protocolTLS

🚩 flagsFinished

src→93.184.216.34:443

dst→192.168.1.2:52345

data→Encrypted handshake hash

flags→Finished

Finished: client→server

ChangeCipherSpec: server→client

Finished: server→client

TLS handshake complete, secure connection established

Hop: 11

Client

Server

Finished: client→server

ChangeCipherSpec: server→client

Finished: server→client

Key Takeaways

✓ TLS handshake is a multi-step protocol that establishes trust and encryption before any application data is sent.

Reading code alone hides the sequence and purpose of each message; visualization clarifies the flow and dependencies.

✓ Certificate exchange and verification are critical for authenticating the server and preventing man-in-the-middle attacks.

Visualizing certificate transmission and verification highlights their role in security, which is often abstracted in code.

✓ ChangeCipherSpec messages mark the transition to encrypted communication, ensuring both sides switch synchronously.

Seeing these messages explicitly helps understand how encryption activation is coordinated.

Practice

1. You want to prevent unauthorized access to your internal network by filtering incoming and outgoing traffic based on IP addresses and ports. Which network component is best suited for this task?

easy

A. Proxy server acting as an intermediary for client requests

B. Firewall filtering traffic based on rules

C. Reverse proxy optimizing server load

D. Content Delivery Network (CDN) caching static content

Solution

1. Step 1: Identify the role of each component

   Firewalls are designed to filter network traffic based on IP addresses, ports, and protocols, enforcing security policies.

2. Step 2: Understand Proxy and Reverse Proxy roles

   Proxies forward client requests but do not primarily filter traffic at the network level; reverse proxies handle server-side requests and optimize load.

3. Step 3: CDN role

   CDNs cache content to improve performance but do not filter traffic for security.

4. Final Answer:

   Option B -> Option B

5. Quick Check:

   Firewall is the component that filters traffic based on rules [OK]

Hint: Firewall filters traffic; proxies forward requests.

Common Mistakes:

• Confusing proxy with firewall as a security filter
• Assuming reverse proxy filters traffic like a firewall

2. In which scenario is the IP Hash load balancing algorithm most appropriate compared to Round Robin or Least Connections?

easy

A. When you need to ensure session persistence by routing requests from the same client IP to the same server

B. When servers have highly variable processing speeds and you want to balance load evenly

C. When the number of active connections per server is constantly changing and you want to minimize response time

D. When you want to distribute requests strictly in a cyclic order regardless of client identity

Solution

1. Step 1: Understand IP Hash purpose

   IP Hash uses the client's IP address to consistently route requests to the same backend server, enabling session persistence (sticky sessions).

2. Step 2: Why not Round Robin or Least Connections?

   Round Robin distributes requests evenly without regard to client identity, so it does not guarantee session persistence. Least Connections balances based on current load but also does not ensure the same client hits the same server.

3. Step 3: Match scenarios to algorithms

   When you need to ensure session persistence by routing requests from the same client IP to the same server correctly identifies the scenario where IP Hash is preferred: session persistence. Options A and C describe scenarios better suited for Least Connections or Round Robin. When you want to distribute requests strictly in a cyclic order regardless of client identity describes Round Robin behavior.

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   IP Hash -> session stickiness; Round Robin -> cyclic distribution; Least Connections -> load-aware balancing.

Hint: IP Hash = sticky sessions by client IP

Common Mistakes:

• Confusing Least Connections with session persistence
• Assuming Round Robin can maintain client affinity
• Believing IP Hash balances load evenly regardless of client IP distribution

3. Trace the sequence of events when a TCP sender receives three duplicate ACKs for the same sequence number. What happens next?

easy

A. The sender ignores duplicate ACKs and continues sending new data segments

B. The sender waits for the retransmission timeout (RTO) before retransmitting the missing segment

C. The sender immediately retransmits the missing segment without waiting for RTO expiration

D. The sender resets the connection due to suspected network failure

Solution

1. Step 1: Understand duplicate ACKs in TCP

   Three duplicate ACKs indicate packet loss but that the network is still delivering packets, triggering fast retransmission.

2. Step 2: Analyze sender's response

   Upon receiving three duplicate ACKs, the sender retransmits the missing segment immediately without waiting for RTO.

3. Step 3: Evaluate options

   The sender ignores duplicate ACKs and continues sending new data segments is incorrect because the sender does not ignore duplicate ACKs. The sender waits for the retransmission timeout (RTO) before retransmitting the missing segment is incorrect because RTO wait is bypassed. The sender immediately retransmits the missing segment without waiting for RTO expiration correctly describes the fast retransmit behavior. The sender resets the connection due to suspected network failure is an extreme reaction not triggered by duplicate ACKs.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Fast retransmit improves performance by avoiding RTO delays.

Hint: 3 duplicate ACKs -> fast retransmit, no RTO wait.

Common Mistakes:

• Confusing fast retransmit with waiting for RTO
• Ignoring duplicate ACKs as noise
• Assuming connection reset on packet loss

4. Which of the following is a significant limitation of the Round Robin load balancing algorithm in a heterogeneous server environment?

medium

A. It depends on client IP hashing which can lead to hotspots

B. It requires maintaining session persistence which increases complexity

C. It can cause uneven load distribution because it ignores server capacity and current load

D. It is computationally expensive due to frequent health checks

Solution

1. Step 1: Understand Round Robin basics

   Round Robin cycles through servers evenly without considering server capacity or load.

2. Step 2: Why is ignoring capacity a problem?

   In heterogeneous environments, servers have different processing power; Round Robin may overload weaker servers and underutilize stronger ones.

3. Step 3: Evaluate other options

   It requires maintaining session persistence which increases complexity is false because Round Robin does not inherently maintain session persistence. It depends on client IP hashing which can lead to hotspots describes IP Hash, not Round Robin. It is computationally expensive due to frequent health checks is unrelated; health checks are separate from Round Robin logic.

4. Final Answer:

   Option C -> Option C

5. Quick Check:

   Round Robin is simple but blind to server differences, leading to uneven load in mixed environments.

Hint: Round Robin ignores server load and capacity

Common Mistakes:

• Confusing Round Robin with IP Hash or Least Connections
• Assuming Round Robin maintains session persistence
• Believing Round Robin is computationally heavy

5. Which of the following statements about WebSockets is INCORRECT?

medium

A. WebSocket communication is inherently secure and does not require additional encryption layers

B. WebSocket connections start as HTTP requests and then upgrade to a persistent full-duplex socket

C. WebSocket reduces latency by avoiding HTTP request-response overhead after connection establishment

D. WebSocket supports bidirectional communication allowing both client and server to send messages independently

Solution

1. Step 1: Review WebSocket handshake

   WebSocket connections begin as HTTP requests and upgrade to a persistent socket (WebSocket connections start as HTTP requests and then upgrade to a persistent full-duplex socket is correct).

2. Step 2: Consider security aspects

   WebSocket itself is a protocol and does not guarantee encryption; secure WebSocket (wss://) uses TLS for encryption. So, WebSocket communication is not inherently secure (WebSocket communication is inherently secure and does not require additional encryption layers is incorrect).

3. Step 3: Analyze latency and communication

   WebSocket reduces latency by avoiding repeated HTTP overhead (WebSocket reduces latency by avoiding HTTP request-response overhead after connection establishment correct) and supports bidirectional communication (WebSocket supports bidirectional communication allowing both client and server to send messages independently correct).

4. Final Answer:

   Option A -> Option A

5. Quick Check:

   WebSocket requires TLS (wss://) for secure communication; it is not secure by default

Hint: WebSocket = HTTP upgrade + optional TLS for security

Common Mistakes:

• Assuming WebSocket is always encrypted
• Confusing WebSocket handshake with normal HTTP
• Believing WebSocket is unidirectional