Detailed Walkthrough of TLS 1.2 Handshake Using Wireshark

Using Postman we initiate an HTTPS POST request to the Weibo homepage and capture the TLS traffic with Wireshark, extracting the TLS protocol packets for analysis.

The first packet sent by the client is ClientHello , which contains the client’s highest supported TLS version (TLS 1.2), a random number (client_random), a session ID (optional), a list of 18 cipher suites, compression methods, and extensions. The most important fields are the random number and the cipher‑suite list.

ClientHello Details

client_version : TLS 1.2

random : ee8880e816ac14ca5b69bde656c188f37a08bcf2052a550b7867b041f6c1ab48

session_id : used for session resumption if supported by the server.

cipher_suites : 18 entries; example TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ECDHE_RSA key exchange, AES‑128‑GCM symmetric encryption, SHA‑256 hash).

compression_methods and extensions follow the same pattern.

ServerHello Details

The server replies with ServerHello , containing its TLS version, a server‑generated random number (server_random), the selected cipher suite, and extensions.

server_version : highest version supported by the server.

random : 3ad03af5b8a5ebfe7902a250406b2e99d2667e37e524e0e5c333c0e0b9a637e8

session_id : either echoes the client’s ID for resumption or provides a new one.

cipher_suite : the server chose 0xc02f , which corresponds to TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 .

Server Certificate

Immediately after ServerHello the server sends a Certificate message containing its X.509 certificate chain. The certificate fields are parsed as follows:

Version : v3

Serial Number : 0x0de81066db219caef5ecb01ba273cad1

Signature Algorithm : sha256WithRSAEncryption

Issuer : DigiCert Inc (GeoTrust CN RSA CA G1)

Validity : 2020‑06‑09 00:00:00 UTC to 2022‑05‑15 12:00:00 UTC

Subject : CN=weibo.cn, O=Sina.com Technology(China)Co., Ltd, C=CN, ST=Beijing

Subject Public Key : 3082010a0282010100c4c84f…

The certificate can also be inspected via the browser’s lock‑icon UI.

Server Key Exchange

Because the chosen cipher suite uses ECDHE, the server sends an ECDHE key‑exchange structure containing:

named_curve and its base point.

Server public key (Pubkey) : 2ce174dbdb6f481b6ab9fd37446dca95b6ade3613afba03243d163360f63713b

The server’s private ECDHE key is not visible in the capture.

Client Key Exchange

The client responds with its own ECDHE public key:

f04e0743377afb5e9bf0a84aec5c7257957b85daee98fc48fb8971a26b457077

The corresponding private key remains secret.

Master Secret Derivation

Both sides now have three values: client_random, server_random, and the pre‑master secret derived from the ECDHE exchange. They combine these to compute the master_secret , which will be used for all subsequent symmetric encryption.

ChangeCipherSpec and Finish Messages

Both client and server send ChangeCipherSpec to indicate that future records will be encrypted with the newly derived master secret, followed by Finish messages that contain a MAC of all previous handshake data encrypted with the master secret. Successful verification confirms that both parties share the same secret.

Application Data

After the handshake, actual HTTP payloads are exchanged as encrypted Application Data records.

Summary of Handshake Steps

1. Client → Server: ClientHello (random + cipher suites). 2. Server → Client: ServerHello (random + selected suite). 3. Server → Client: Certificate (X.509 chain). 4. Server → Client: ServerKeyExchange (ECDHE parameters). 5. Server → Client: ServerHelloDone. 6. Client → Server: ClientKeyExchange (client ECDHE public key). 7. Client → Server: ChangeCipherSpec + Finish. 8. Server → Client: ChangeCipherSpec + Finish. 9. Both: Encrypted Application Data.

These three phases—client hello, server hello, and key‑exchange—establish a shared symmetric key, after which normal encrypted communication proceeds.