1. C->S：Client Hello
2. S->C：Server Hello
3. S->C：Certificate, Server Key Exchange, Server Hello Done
4. C->S：Client Key Change
5. C->S：Change Cipher Spec
6. C->S：Encryted Handshake Message
7. S->C：Change Cipher Spec, Encryted Handshake Message
8. C->S/S->C：Application Data

第 1、2、3、4、6、7.2 步均為 TLSv1.2 Record Layer 中的 Handshake Protocol，
第 5、7.1 步為 TLSv1.2 Record Layer 中的 Change Cipher Spec Protocol，
第 8 步為 TLSv1.2 Record Layer 中的 Application Data Protocol: http-over-tls。

與 rfc4492-Message_flow_in_a_full_TLS_handshake 對比，伺服器沒有要求 client authentication，即不涉及 *+ 步驟。

在 Wireshark 解析樹中，TLS 被解析為 Secure Sockets Layer。

The protocol is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol.
TLS wraps all traffic in “records” of different types. A TLS message may span multiple TLS records.
The handshake record is broken out into several messages.

Client Hello

TLSv1.2 Record Layer: Handshake Protocol: Client Hello

ssl.record.content_type=0x16
ssl.handshake.type=0x01

• TLS Version
• Random
• Compression Methods
• Extension: server_name(Server Name Indication extension)
• Extension: elliptic_curves(EllipticCurveList)
• Extension: ec_point_formats(ECPointFormatList)
• Extension: signature_algorithms
• Extension: next_protocol_negotiation
• Extension: Application Layer Protocol Negotiation(ALPN Protocol)
• Extension: signed_certificate_timestamp
• Extension: Extended Master Secret

ssl.record 頭部的 Version 為 TLS 1.0(0x0301)，為客戶端首次發起 Hello 選擇的最低版本。ssl.handshake 報文中的 Version 為 TLS 1.2(0x0303)，為客戶端支援的 TLS 最高版本。

所有的列舉能力項（Cipher Suites,Compression Methods,elliptic_curves,ec_point_formats,signature_algorithms,etc）都是按照從高到低的優先順序排列(favorite choice first)。

Signature Hash Algorithm 包括 Hash 演算法 和 Signature 演算法。

Server Hello

TLSv1.2 Record Layer: Handshake Protocol: Server Hello

ssl.record.content_type=0x16
ssl.handshake.type=0x02

• TLS Version
• Random
• Session ID, (黑體新增)
• Cipher Suite, (斜體協定)
• Compression Method
• Extension: renegotiation_info
• Extension: server_name(Server Name Indication extension)
• Extension: ec_point_formats(ECPointFormatList)
• Extension: Extended Master Secret
• Extension: Application Layer Protocol Negotiation(ALPN Next Protocol: http/1.1)

ssl.record 頭部的 Version 為 TLS 1.2(0x0303)，表示 Server 迴應 Hello 使用的版本為 TLS 1.2。ssl.handshake 報文中的 Version 也為 TLS 1.2(0x0303)。

Hello Extensions is “client-oriented“:

the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello.
the extended server hello message is only sent in response to an extended client hello message.

ssl.record 總長117，各部分長度構成如下：

• sizeof(ssl.record.content_type)=1
• sizeof(ssl.record.version)=2
• sizeof(ssl.record.length)=2
• sizeof(ssl.handshake)=112

報文(#8) 幀長 1490（tcp payload 長度為 1424），出現了 TCP 報文流粘連，117 位元組的 Server Hello 後面還有 1307 個位元組是伺服器傳送的證書報文。

Certificate

TLSv1.2 Record Layer: Handshake Protocol: Certificate

ssl.record.content_type=0x16
ssl.handshake.type=0x0b

This message conveys the server’s certificate chain to the client.

報文(#8) 包含證書的前 1307 個位元組，報文(#9)為證書的中間部分（TCP Segment Len: 1424）。

報文(#10) 幀長 827（tcp payload 長度為 761），也出現了 TCP 報文流粘連：

• 414 位元組的證書結尾部分；
• 338 位元組的 Server Key Exchange 報文；
• 9 位元組的 Server Hello Done 報文。

整個證書 Certificate 報文由3個TCP流組成：

[3 Reassembled TCP Segments (3145 bytes): #8(1307), #9(1424), #10(414)]

ssl.record 各部分長度構成如下：

• sizeof(ssl.record.content_type)=1
• sizeof(ssl.record.version)=2
• sizeof(ssl.record.length)=2
• sizeof(ssl.handshake)=3140

正如 rfc4492 所述，The server’s Certificate message is capable of carrying a chain of certificates.
Certificate 報文下發了 GitHub 機構旗下 github.com 網站的證書及其頒發機構 DigiCert 的證書：

// 二級證書(1917 bytes)
Certificate: 3082077930820661a00302010202100bfdb4090ad7b5e640... (id-at-commonName=github.com,id-at-organizationName=GitHub, Inc.,id-at-localityName=San Francisco,id-at-stateOrProvinceName=California,id-at-countryName=US,id-at-postalCode=9

// 一級證書(1210 bytes)
Certificate: 308204b63082039ea00302010202100c79a944b08c119520... (id-at-commonName=DigiCert SHA2 Extended Validation Server CA,id-at-organizationalUnitName=www.digicert.com,id-at-organizationName=DigiCert Inc,id-at-countryName=US)

在 wireshark 中可依次展開 Certificate|signedCertificate 檢視證書頒發機構（issuer）和證書持有主體（subject）資訊及其公鑰資訊（subjectPublicKeyInfo）。其中 signature 指定了認證籤密演算法，encrypted 部分為使用 DigiCert 私鑰加過密的簽名。

也可右鍵選單 匯出分組位元組流，可匯出 Certificate 欄位值的分組位元組流（raw 二進位制），並儲存為 *.cer。在 macOS 下雙擊自動將證書匯入鑰匙串（Keychain Access），然後在鑰匙串中可雙擊開啟檢視證書內容。

Actions of the receiver

The client validates the certificate chain, extracts the server’s public key, and checks that the key type is appropriate for the negotiated key exchange algorithm.

Server Key Exchange

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange

ssl.record.content_type=0x16
ssl.handshake.type=0x0c

This message is used to convey the server’s ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client.

交換 ECDH 引數（EC Diffie-Hellman Server Params）：

• TLS Version
• Curve Type: named_curve
• Named Curve: secp256r1
• Pubkey
• Signature Hash Algorithm(Hash: SHA512, Signature: RSA)
• Signature

傳輸了 Curve Type 及其對應值（elliptic curve domain parameters）、Pubkey（The ephemeral ECDH public key） 及其對應簽名(及其雜湊簽名演算法)。

Actions of the sender/receiver

The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [6].

The client verifies the signature (when present) and retrieves the server’s elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message.

Server Hello Done

TLSv1.2 Record Layer: Handshake Protocol: Server Hello Done

ssl.record.content_type=0x16
ssl.handshake.type=0x0e

The ServerHelloDone message is sent by the server to indicate the end of the ServerHello and associated messages.
After sending this message, the server will wait for a client response.

Client Key Exchange

TLSv1.2 Record Layer: Handshake Protocol: Client Key Exchange

ssl.record.content_type=0x16
ssl.handshake.type=0x10

交換 ECDH 引數（EC Diffie-Hellman Client Params）：

• TLS Version
• Pubkey

It MUST immediately follow the client certificate message, if it is sent. Otherwise, it MUST be the first message sent by the client after it receives the ServerHelloDone message.

With this message, the premaster secret is set, either by direct transmission of the RSA-encrypted secret or by the transmission of Diffie-Hellman parameters that will allow each side to agree upon the same premaster secret.

Actions of the sender/receiver

The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363 [6].

The server retrieves the client’s ephemeral ECDH public key from the
ClientKeyExchange message and checks that it is *on the same elliptic
curve* as the server’s ECDH key.

Change Cipher Spec(C)

ssl.record.content_type=0x14

• TLS Version
• Change Cipher Spec Message

The change cipher spec protocol exists to signal transitions in ciphering strategies.
It means has finished computing the new keying material.

The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon, but before the verifying Finished message is sent.

The ChangeCipherSpec message is sent by both the client and the server to notify the receiving party that subsequent records will be protected under the newly negotiated CipherSpec and keys.

Reception of this message causes the receiver to instruct the record layer to immediately copy the read pending state into the read current state.
Immediately after sending this message, the sender MUST instruct the record layer to make the write pending state the write active state.

Encryted Handshake Message(C)

TLS Client Finished

ssl.record.content_type=0x16

• TLS Version
• Encrypted Handshake Message

verify that their peer has calculated the same security parameters.

A Finished message is always sent immediately after a change cipher spec message to verify that the key exchange and authentication processes were successful.
It is essential that a change cipher spec message be received between the other handshake messages and the Finished message.

The Finished message is the first one protected with the just negotiated algorithms, keys, and secrets.
Recipients of Finished messages MUST verify that the contents are correct.
Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection.

Change Cipher Spec(S)

ssl.record.content_type=0x14

• TLS Version
• Change Cipher Spec Message

機制同 Change Cipher Spec(C)。

Encryted Handshake Message(S)

TLS Server Finished

ssl.record.content_type=0x16

• TLS Version
• Encrypted Handshake Message

機制同 Encryted Handshake Message(C)。

參考