Can HTTPS Stop Replay Attacks? Deep Dive into TLS Handshake and MAC

Introduction

Interview scenario: A candidate claims to know only basic HTTPS/HTTP. The interviewer asks about the HTTPS main process and whether a man‑in‑the‑middle replay attack can be prevented.

Protocol Flow

HTTPS = HTTP + SSL/TLS. The handshake (RSA key exchange example) proceeds as:

Client sends a random number client_random and the TLS version.

Server replies with its random number server_random and its certificate.

Client validates the certificate and extracts the server’s public key.

Client generates pre_master_secret, encrypts it with the server’s public key, and sends it to the server.

Server decrypts pre_master_secret with its private key.

Both sides compute the master secret master_secret from client_random, server_random and pre_master_secret, then discard pre_master_secret.

From the master secret the key block is derived:

key_block = PRF(master_secret, "key expansion", server_random + client_random)

The key block yields six keys:

client_write_MAC_key

server_write_MAC_key

client_write_key

server_write_key

client_write_IV

server_write_IV

Both client and server hold these keys, using the client‑prefixed ones for traffic sent by the client and the server‑prefixed ones for traffic sent by the server.

Encryption Process

TLS can work in stream, block, or AEAD modes. Using stream mode, data is encrypted with the write key, then a MAC is appended for integrity.

MAC Formula

HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)

The seq_num is a monotonically increasing sequence number that prevents replay attacks. Both client and server maintain separate send/receive counters (client_send, client_recv, server_send, server_recv). When a message is sent, the current send counter is used as seq_num and then incremented; the receiver verifies the MAC using its receive counter and then increments it.

If an attacker replays a previously captured record, the seq_num will not match the receiver’s expected value, causing MAC verification to fail and the replay to be rejected.

Thought Exercise

Consider a TCP connection represented by packet numbers [0,1,2,3,…]. Within a single connection TLS can detect replay because of the sequence numbers. What about replay across separate connections? Can HTTPS still block it? Think about the role of the initial random values.

For more details, see the TLS 1.0 specification: https://www.rfc-editor.org/rfc/rfc2246.html