在「碼了2000多行代碼就是為了講清楚TLS握手流程」這一篇文章的最後挖了一個坑，今天這篇文章就是為了填坑而來，因此本篇主要分析TLS1.2的握手流程。
在寫前一篇文章時，筆者的Demo只支持解析TLS1.3握手流程中發送的消息，寫本篇時，筆者的Demo已經可以解析TLS1.x握手流程中的消息，有興趣的讀者請至文末獲取Demo源碼。
結論先行為保證各位讀者對TLS1.2的握手流程有一個大概的框架，本篇依舊結論先行。
單向認證單向認證客戶端不需要證書，客戶端驗證服務端證書合法即可訪問。
下面是筆者運行Demo列印的調試信息：
根據調試信息知，TLS1.2單向認證中總共收發數據四次，Client和Server從這四次數據中分別讀取不同的信息以達到握手的目的。
筆者將調試信息轉換為下述時序圖，以方便各位讀者理解。
雙向認證雙向認證不僅服務端要有證書，客戶端也需要證書，只有客戶端和服務端證書均合法才可繼續訪問（筆者的Demo如何開啟雙向認證請參考前一篇文章中HTTPS雙向認證部分）。
下面是筆者運行Demo列印的調試信息：
同單向認證一樣，筆者將調試信息轉換為下述時序圖。
雙向認證和單向認證相比，Server發消息給Client時會額外發送一個certificateRequestMsg消息，Client收到此消息後會將證書信息（certificateMsg）和籤名信息（certificateVerifyMsg）發送給Server。
雙向認證中，Client和Server發送的消息變多了，但是總的數據收發仍然只有四次。
總結1、單向認證和雙向認證中，總的數據收發僅四次（比TLS1.3多一次數據收發），單次發送的數據中包含一個或者多個消息。
2、TLS1.2中除了finishedMsg其餘消息均未加密。
3、在TLS1.2中，ChangeCipherSpec消息之後的所有數據均會做加密處理，它的作用在TLS1.2中更像是一個開啟加密的開關（TLS1.3中忽略此消息，並不做任何處理）。
和TLS1.3的比較消息格式的變化對比本篇的時序圖和前篇的時序圖很容易發現部分消息格式發生了變化。下面是certificateMsg和certificateMsgTLS13的定義：
// TLS1.2
type certificateMsg struct {
raw []byte
certificates [][]byte
}
// TLS1.3
type certificateMsgTLS13 struct {
raw []byte
certificate tls.Certificate
ocspStapling bool
scts bool
}其他消息的定義筆者就不一一列舉了，這裡僅列出格式發生變化的消息。
TLS1.2TLS1.3certificateRequestMsgcertificateRequestMsgTLS13certificateMsgcertificateMsgTLS13消息類型的變化TLS1.2和TLS1.3有相同的消息類型也有各自獨立的消息類型。下面是筆者例子中TLS1.2和TLS1.3各自獨有的消息類型：
TLS1.2TLS1.3serverKeyExchangeMsg-clientKeyExchangeMsg-serverHelloDoneMsg--encryptedExtensionsMsg消息加密的變化前篇中提到，TLS1.3中除了clientHelloMsg和serverHelloMsg其他消息均做了加密處理，且握手期間和應用數據使用不同的密鑰加密。
TLS1.2中僅有finishedMsg做了加密處理，且應用數據也使用該密鑰加密。
TLS1.3會計算兩次密鑰，Client和Server讀取對方的HelloMsg和finishedMsg之後即可計算密鑰。
「Client和Server會各自計算兩次密鑰，計算時機分別是讀取到對方的HelloMsg和finishedMsg之後」，這是前篇中的描述，計算時機描述不準確以上面為準。
TLS1.2隻計算一次密鑰，Client和Server分別收到serverKeyExchangeMsg和clientKeyExchangeMsg之後即可計算密鑰，和TLS1.3不同的是TLS1.2密鑰計算後並不會立即對接下來發送的數據進行加密，只有當發送/接受ChangeCipherSpec消息後才會對接下來的數據進行加解密。
生成密鑰過程TLS1.2和TLS1.3生成密鑰的過程還是比較相似的， 下圖為Client讀取serverKeyExchangeMsg之後的部分處理邏輯：
圖中X25519是橢圓曲線迪菲-赫爾曼（Elliptic-curve Diffie–Hellman ，縮寫為ECDH）密鑰交換方案之一，這在前篇已經提到過故本篇不再贅述。
根據Debug結果，本例中ka.preMasterSecret和TLS1.3中的共享密鑰生成邏輯完全一致。不僅如此，在後續的代碼分析中，筆者發現TLS1.2也使用了AEAD加密算法對數據進行加解密（AEAD在前篇中已經提到過故本篇不再贅述）。
下圖為筆者Debug結果：
圖中prefixNonceAEAD即為TLS1.2中AEAD加密算法的一種實現。
這裡需要注意的是TLS1.3也會計算masterSecret。為了方便理解，我們先回顧一下TLS1.3中生成masterSecret的部分源碼：
// 基於共享密鑰派生hs.handshakeSecret
hs.handshakeSecret = hs.suite.extract(hs.sharedKey,
hs.suite.deriveSecret(earlySecret, "derived", nil))
// 基於hs.handshakeSecret 派生hs.masterSecret
hs.masterSecret = hs.suite.extract(nil,
hs.suite.deriveSecret(hs.handshakeSecret, "derived", nil))由上易知，TLS1.3先通過共享密鑰派生出handshakeSecret，最後通過handshakeSecret派生出masterSecret。與此相比，TLS1.2生成masterSecret僅需一步：
hs.masterSecret = masterFromPreMasterSecret(c.vers, hs.suite, preMasterSecret, hs.hello.random, hs.serverHello.random)masterFromPreMasterSecret函數的作用是利用HMAC（HMAC在前篇中已經提到故本篇不再贅述）算法對Client和Server的隨機數以及共享密鑰進行摘要，從而計算得到masterSecret。
masterSecret在後續的過程中並不會用於數據加密，下面筆者帶各位讀者分別看一下TLS1.3和TLS1.2生成數據加密密鑰的過程。
TLS1.3生成數據加密密鑰（以Client計算serverSecret為例）：
serverSecret := hs.suite.deriveSecret(hs.masterSecret,
serverApplicationTrafficLabel, hs.transcript)
c.in.setTrafficSecret(hs.suite, serverSecret)前篇中提到hs.suite.deriveSecret內部會通過hs.transcript計算出消息摘要從而重新得到一個serverSecret。setTrafficSecret方法內部會對serverSecret計算得到AEAD加密算法所需要的key和iv（初始向量：Initialization vector）。
因此可知TLS1.3計算密鑰和Client/Server生成的隨機數無直接關係，而與Client/Server當前收發的所有消息的摘要有關。
補充：IV通常是隨機或者偽隨機的。它和數據加密的密鑰一起使用可以增加使用字典攻擊的攻擊者破解密碼的難度。例如，如果加密數據中存在重複的序列，則攻擊者可以假定消息中相應的序列也是相同的，而IV就是為了防止密文中出現相應的重複序列。
參考：
https://whatis.techtarget.com/definition/initialization-vector-IV
https://en.wikipedia.org/wiki/Initialization_vector
TLS1.2生成數據加密密鑰：
clientMAC, serverMAC, clientKey, serverKey, clientIV, serverIV :=
keysFromMasterSecret(tr.vers, suite, p.masterSecret, tr.clientHello.random, tr.serverHello.random, suite.macLen, suite.keyLen, suite.ivLen)
serverCipher = hs.suite.aead(serverKey, serverIV)
c.in.prepareCipherSpec(c.vers, serverCipher, serverHash)前文中提到masterSecret的生成與Client和Server的隨機數有關，而通過keysFromMasterSecret計算AEAD所需的key和iv依舊與隨機數有關。
小結：
1、本例中TLS1.2和TLS1.3均使用X25519算法計算共享密鑰。
2、本例中TLS1.2和TLS1.3均使用AEAD進行數據加解密。
3、TLS1.3通過共享密鑰派生兩次才得到masterSecret，而TLS1.2以共享密鑰、Client和Server的隨機數一起計算得到masterSecret。
4、TLS1.3通過消息的摘要再次計算得到一個數據加密密鑰，而TLS1.2直接通過masterSecret計算得到AEAD所需的key和iv。
TLS1.1和TLS1.0不支持HTTP2在前面提到本文的例子已經支持解析TLS1.x的握手流程，這個時候筆者突然很好奇瀏覽器還支持那些版本的TLS協議。
然後筆者在谷歌瀏覽器上首先測試了TLS1.1的服務，為了方便測試筆者改造了之前伺服器推送的案例：
server := &http.Server{Addr: ":8080", Handler: nil}
server.TLSConfig = new(tls.Config)
server.TLSConfig.PreferServerCipherSuites = true
server.TLSConfig.NextProtos = append(server.TLSConfig.NextProtos, "h2", "http/1.1")
// 服務端支持的最大tls版本調整為1.1
server.TLSConfig.MaxVersion = tls.VersionTLS11
server.ListenAndServeTLS("ca.crt", "ca.key")運行Demo後得到如下截圖：
圖中紅框部分obsolete的意思筆者也不知，正好學習一波（技術人的英語大概就是這樣慢慢積累起來的吧）。
這下筆者明白了，TLS1.1已經不被支持所以頁面才無法正常訪問，然而事實真是如此嘛？
直到幾天後筆者開始寫這篇文章時，內心仍是十分疑惑，於是使用了curl命令再次訪問。
圖中藍框部分正是TLS1.1的握手流程，有興趣的讀者可以使用筆者的例子和curl -v命令進行雙向驗證。
圖中紅框部分提示說「HTTP2的數據發送失敗」，筆者才恍然大悟，將上述代碼作如下微調後頁面可正常訪問。
server.TLSConfig.NextProtos = append(server.TLSConfig.NextProtos, "http/1.1")經過筆者的測試，TLS1.0同TLS1.1一樣均不支持HTTP2協議，當然這兩個協議也不推薦繼續使用。
寫在最後「紙上得來終覺淺，絕知此事需躬行」。筆者不敢保證把TLS握手流程的每個細節都講的十分清楚，所以建議各位讀者去github克隆代碼，然後自己一步一步Debug必然能夠加深印象並徹底理解。當然，順便關注或者star一下這種隨手為之的小事，筆者相信各位讀者還是十分樂意的～
最後，衷心希望本文能夠對各位讀者有一定的幫助。
註：
寫本文時， 筆者所用go版本為: go1.15.2
文章中所用完整例子：https://github.com/Isites/go-coder/blob/master/http2/tls/main.go
長按二維碼關注公眾號，查看更多分享。
不會吧，不會吧，不會真的有人白嫖吧。素質三連（分享、點讚、在看）都是筆者持續創作更多優質內容的動力！