TLS 1.2 簡介
TLS概述：TLS和他的前身SSL，都是提供在計算機網絡上安全通信的密碼學協議，最常見就是用於HTTPS中，用來保護Web通信的。
發展史：網景公司開發了原始的SSL協議，SSL 1.0因為本身存在着嚴重的安全問題，所以從未被公開發布。只有SSL 2.0和SSL 3.0是被公開發布和使用的。
后來為了對SSL進行標准化，推出了TLS，TLS 1.0就對應着SSL 3.0。
TLS后來又有了1.1版本和1.2版本，1.3版本目前還在草案中。
現在除了TLS 1.2和TLS 1.3草案之外，所有早期的協議都存在安全性問題，不建議使用。
我們今天的話題是TLS 1.2，首先分析TLS 1.2的整個體系結構，然后會借助其通信的報文進行詳細分析。
TLS 1.2 的體系結構
首先TLS是一個高層協議，工作在計算機網絡五層模型的上面兩層，也就是Transport層（傳輸層）和Application層（應用層）。
今天主要介紹的是TLS 1.2在HTTPS環境下的應用。TLS 1.2不止可以用於Web通信，還可以用於其他的通信方式，只是今天以Web通信為例介紹。
整個TLS 1.2的概述：TLS 1.2實際上目的是在Web服務器和客戶端瀏覽器之間建立安全連接。要想建立安全連接，必須通過密鑰交換協議協商出一個共同的密鑰（一般我們稱為Handshake），然后再利用對稱密碼進行加密傳輸 [1]。這個過程中為了避免中間人攻擊，還需要通過數字證書保護公鑰 [2]。這些就是TLS 1.2的基本任務，即證書認證、密鑰協商以及加密傳輸。
[1] 對稱密碼體制要求通信雙方必須有一個兩方都知道的密鑰，這個密鑰必須通過保密的方式傳送，而實際上計算機網絡本身並不保密。所以如何在不安全的網絡上“協商”出一個安全密鑰，這是個很大的問題。詳見密鑰交換協議。
[2] 通過公鑰密碼體制，允許雙方各持有公鑰和私鑰進行通信，但是密鑰的協商過程中依舊可能被欺騙，這稱為中間人攻擊。數字證書是為了解決這個問題。詳見數字證書。
所以從整體來看，TLS 1.2做了以下的工作：在TCP連接建立之后，首先客戶端驗證服務器的證書，在安全性要求高的情況下服務器還會驗證客戶端的證書。然后兩者開始協商加密密鑰，協商完成之后，就利用這個密鑰開始加密通信了。我們通過實際的報文來看看這個過程。
TLS 1.2的通信流程
1. TCP的三次握⼿ 前三個報⽂是TCP建⽴連接的過程，本例中客戶端⾸先發起連接，客戶端向服務器發送SYN報⽂，服務器接收到之后回復SYN ACK確認，之后客戶端再向服務器發送ACK確 認。通過三次交互，⼀個TCP連接就建⽴起來了。 本⽂⽆意討論TCP三次握⼿的過程，讀者如果不理解的可以查閱相關資料，這⾥只需要理解這三次握⼿是通過TCP協議通信的必經之路就好了。 需要注意的是，如果按照HTTP協議的規定，建⽴TCP連接之后，就可以正式開始通信了，客戶端可以構建HTTP請求，來請求服務器上的⻚⾯，服務器也會按照要求進⾏響 應。但是這個過程是完全不進⾏加密的，並沒有安全性可⾔。這部分屬於TCP的范疇，下⾯我們才真正開始討論TLS 1.2。 2. Client Hello 客戶端發送的，屬於TLS握⼿協議（TLS handshake）的⼀部分，其內容包括客戶端的⼀個Unix時間戳（GMT Unix Time）、⼀些隨機的字節（Random Bytes），還包括 了客戶端接受的算法類型（Cipher Suites），本例中Mozilla Firefox 57.0允許15種算法，瀏覽器認為這些算法是可以被信任的。這是最基本的部分，同時還有其他的擴展參 數，這⾥就不做介紹了。 Client Hello的⽬的就類似於SYN，客戶端對服務器公布⾃⼰⽀持的算法等等，同時也附帶請求服務器證書的意思。這⾥不驗證客戶端證書，所以Client Hello就只有這些內 容。 3. Server Hello 服務器發送的，同樣屬於TLS handshake，內容包括服務器的GMT Unix Time以及Random Bytes，和上⾯類似就不再解釋。這時候服務器會將⾃⼰⽀持的算法類型發送給 客戶端，以便於客戶端進⾏驗證，這⾥我的服務器使⽤的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，也就是使⽤AES-128的GCM模式進⾏對稱加密，同時以帶 SHA-256的RSA作為簽名算法，⽤ECDHE做密鑰交換的⼀整套協議。我的服務器也算是主流安全啦～ Server Hello⽬的就是服務器對客戶端公布⾃⼰的算法，以便於后續操作。 4. Certificate 服務器或者客戶端發送的，依舊屬於TLS handshake，它⼀般和Server Hello在同⼀個TCP報⽂中傳送。顯然的，這⾥服務器將⾃⼰的數字證書發送給客戶端，客戶端就會 進⾏證書驗證，如果不通過的話，客戶端會中斷握⼿的過程。如果也要求客戶端提供證書的話，Client Hello后⾯也會緊跟着該報⽂，形式完全⼀樣，就不再解釋了。 5. Server Key Exchange 服務器發送的，屬於TLS handshake，⼀般也和Server Hello與Certificate在⼀個TCP報⽂中。服務器將⾃⼰的公鑰參數傳輸給了客戶端，因為使⽤的是ECDHE，這⾥傳輸 的內容有：橢圓曲線域參數，以及公鑰的值。 這個就是密鑰交換協議的⼀部分，最終協商出密鑰來。 6. Server Hello Done 服務器發送的，屬於TLS handshake，⼀般也和Server Hello、Certificate和Server Key Exchange在⼀個TCP報⽂中，介於Server Hello和Server Hello之間的是服務器想 要給客戶端的東⻄。所以這⾥⾯客戶端沒有發送Client Hello Done 7. Client Key Exchange 客戶端發送的，屬於TLS handshake，客戶端收到了服務器的證書進⾏驗證，如果驗證通過了，就會繼續密鑰交換的過程，向服務器發送⾃⼰的公鑰參數。待服務器收到之 后進⾏數學計算，就可以協商出密鑰了，這⾥客戶端實際上已經計算出了密鑰。 8. Change Cipher Spec 客戶端或者服務器發送的，屬於TLS handshake，緊跟着Key Exchange發送，代表⾃⼰⽣成了新的密鑰，通知對⽅以后將更換密鑰，使⽤新的密鑰進⾏通信。 9. Encrypted Handshake Message 客戶端或者服務器發送的，屬於TLS handshake，也是緊跟着Key Exchange發送。這⾥是進⾏⼀下測試，⼀⽅⽤⾃⼰的剛剛⽣成的密鑰加密⼀段固定的消息發送給對⽅， 如果密鑰協商正確⽆誤的話，對⽅應該可以解密。這段加密內容的明⽂⼀般是協議中規定好的，雙⽅都知道。 10. New Session Ticket 服務器發送的，屬於TLS handshake，服務器給客戶端⼀個會話，⽤處就是在⼀段時間之內（超時時間到來之前），雙⽅都以剛剛交換的密鑰進⾏通信。從這以后，加密通 信正式開始。 11. Application Data 應⽤層的數據，是加密的，使⽤密鑰交換協議協商出來的密鑰加密。因為我們的Wireshark不知道服務器的私鑰，所以這段通信是安全的，我們在Wireshark中也⽆法解密 這段信息。 12. Encrypted Alert 客戶端或服務器發送的，意味着加密通信因為某些原因需要中斷，警告對⽅不要再發送敏感的數據。
總結
本⽂粗略的介紹了TLS協議的1.2版本的通信過程，重點是handshake的過程，以上部分完成了證書認證、密鑰協商以及加密傳輸的任務。
在我看來，計算機⽹絡有⼀種獨特的魅⼒，那就是⼈們在設計⽹絡協議的時候，也完全是按照⼈類的思維進⾏的設計。實際上在各種各樣的⽹絡協議中，處處流淌着⼈類的
思想，體現着⼈類的⽂化。就⽐如本⽂介紹的TLS，就好像服務器和客戶端是兩個⼈在對話⼀樣。事實就是如此，計算機⽹絡就是計算機之間“對話”的科學。這也是我對計
算機⽹絡的興趣所在。