Inside a 220 ms TLS Handshake: How Firefox Secures Your Amazon Purchase

Using Wireshark, the author captures a Firefox‑initiated HTTPS connection to Amazon.com and dissects every step that occurs within the first 220 ms after the user clicks the checkout button.

Client Hello

The client sends a TLS handshake record (type 0x16) containing version 0x0301 (TLS 1.0), a 4‑byte Unix timestamp, 28 bytes of random data, an empty Session ID, a list of supported cipher suites (including the preferred TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ), and a Server Name extension indicating www.amazon.com.

Server Hello

Amazon replies with a 2551‑byte handshake record that includes its own timestamp, a 28‑byte random value, a 32‑byte Session ID for session resumption, and selects the cipher suite TLS_RSA_WITH_RC4_128_MD5 (0x0004).

Certificate

The server sends a 2464‑byte X.509 certificate signed by VeriSign Class 3 Secure Server CA. The certificate contains the public modulus (2048‑bit) and exponent, which the client will later use for RSA encryption.

Certificate Validation

The client checks the certificate’s validity period (2008‑08‑26 to 2009‑08‑27), the signature, and that the hostname matches www.amazon.com, thereby establishing trust in the server’s public key.

RSA Encryption Basics

The article briefly reviews RSA key generation (n = p·q, public exponent e, private exponent d) and shows the encryption formula C ≡ M^e (mod n) and the corresponding decryption formula.

Pre‑Master Secret

Firefox generates a 48‑byte random pre‑master secret, prefixes it with the TLS version (0x0301), and sends it encrypted with the server’s RSA public key. The raw bytes are logged by the debug output:

4456: SSL[131491792]: Pre‑Master Secret [Len: 48]
03 01 bb 7b 08 98 a7 49 de e8 e9 b8 91 52 ec 81 ...
4c c2 39 7b f6 ba 1c 0a b1 95 50 29 be 02 ad e6
ad 6e 11 3f 20 c4 66 f0 64 22 57 7e e1 06 7a 3b

Master Secret Derivation

The pre‑master secret, the label "master secret", and the concatenated client and server random values are fed into the TLS pseudo‑random function (PRF) to produce a 48‑byte master secret.

Resulting master secret (hex):

4C AF 20 30 8F 4C AA C5 66 4A 02 90 F2 AC 10 00 39 DB 1D E0 1F CB E0 E0 9D D7 E6 BE 62 A4 6C 18 06 AD 79 21 DB 82 1D 53 84 DB 35 A7 1F C1 01 19

Key Block Generation

The master secret is expanded with the label "key expansion" and the server‑random + client‑random to produce a key block. From this block the client and server MAC secrets and RC4 keys are extracted:

client_write_MAC_secret = 80 B8 F6 09 51 74 EA DB 29 28 EF 6F 9A B8 81 B0
server_write_MAC_secret = 67 7C 96 7B 70 C5 BC 62 9D 1D 1F 4A A6 79 81 61
client_write_key = 32 13 2C DD 1B 39 36 40 84 4A DE E5 6C 52 46 72
server_write_key = 58 36 C4 0D 8C 7C 74 DA 6D B7 34 0A 91 B6 8F A7

Finished Message Verification

Both sides compute a 12‑byte verify_data using the PRF with the label "client finished" (or "server finished") and the concatenated MD5 and SHA‑1 hashes of all handshake messages. This value is sent inside a TLS record of type 0x14.

RC4 Encryption

With the selected cipher suite, RC4 is used to encrypt the application data. The client encrypts each byte by XOR‑ing it with a pseudo‑random byte generated from the 256‑byte S‑array.

Application Layer Traffic

After the handshake, the HTTP GET request for the Amazon cart is encrypted and transmitted:

GET /gp/cart/view.html/ref=pd_luc_mri HTTP/1.1
Host: www.amazon.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.10) Gecko/2009060911 Minefield/3.0.10 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
...

The server’s encrypted response is similarly decrypted on the client side, revealing a standard HTTP 200 OK response.

Conclusion

The 220 ms capture demonstrates how Firefox and Amazon.com negotiate TLS 1.0, verify certificates, perform RSA key exchange, derive symmetric keys, and finally protect the HTTP payload with RC4. The article also notes that stronger cipher suites such as TLS_DHE_RSA_WITH_AES_256_CBC_SHA provide forward secrecy at the cost of higher computational overhead.

Click the lower left corner for more details.