淺析TLS 1.2協議

0x01 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的整個體系結構，而後會藉助其通訊的報文進行詳細分析。

0x02 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鏈接創建以後，首先客戶端驗證服務器的證書，在安全性要求高的狀況下服務器還會驗證客戶端的證書。而後二者開始協商加密密鑰，協商完成以後，就利用這個密鑰開始加密通訊了。咱們經過實際的報文來看看這個過程。

0x03 藉助Wireshark分析TLS 1.2的通訊流程

1. 環境說明

• 服務器IP地址：10.5.24.129
• 服務器操做系統：openSUSE Linux (Leap 42.3)
• 服務器軟件：Apache
• 服務器應用層協議：HTTP 2.0、TLS 1.2
• 客戶端IP地址：10.5.24.130
• 客戶端操做系統：openSUSE Linux (Leap 42.3)
• 客戶端軟件（瀏覽器）：Mozilla Firefox 57.0
• 網絡拓撲：客戶端和服務器直接經過交換機鏈接，不通過任何路由。
• 捕獲軟件：Wireshark 2.2

2. TCP的三次握手

• 前三個報文是TCP創建鏈接的過程，本例中客戶端首先發起鏈接，客戶端向服務器發送SYN報文，服務器接收到以後回覆SYN ACK確認，以後客戶端再向服務器發送ACK確認。經過三次交互，一個TCP鏈接就創建起來了。
• 本文無心討論TCP三次握手的過程，讀者若是不理解的能夠查閱相關資料，這裏只須要理解這三次握手是經過TCP協議通訊的必經之路就行了。
• 須要注意的是，若是按照HTTP協議的規定，創建TCP鏈接以後，就能夠正式開始通訊了，客戶端能夠構建HTTP請求，來請求服務器上的頁面，服務器也會按照要求進行響應。可是這個過程是徹底不進行加密的，並無安全性可言。這部分屬於TCP的範疇，下面咱們才真正開始討論TLS 1.2。

3. Client Hello

• 客戶端發送的，屬於TLS握手協議（TLS handshake）的一部分，其內容包括客戶端的一個Unix時間戳（GMT Unix Time）、一些隨機的字節（Random Bytes），還包括了客戶端接受的算法類型（Cipher Suites），本例中Mozilla Firefox 57.0容許15種算法，瀏覽器認爲這些算法是能夠被信任的。這是最基本的部分，同時還有其餘的擴展參數，這裏就不作介紹了。
• Client Hello的目的就相似於SYN，客戶端對服務器公佈本身支持的算法等等，同時也附帶請求服務器證書的意思。這裏不驗證客戶端證書，因此Client Hello就只有這些內容。

4. 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目的就是服務器對客戶端公佈本身的算法，以便於後續操做。

5. Certificate

• 服務器或者客戶端發送的，依舊屬於TLS handshake，它通常和Server Hello在同一個TCP報文中傳送。顯然的，這裏服務器將本身的數字證書發送給客戶端，客戶端就會進行證書驗證，若是不經過的話，客戶端會中斷握手的過程。若是也要求客戶端提供證書的話，Client Hello後面也會緊跟着該報文，形式徹底同樣，就再也不解釋了。

6. Server Key Exchange

• 服務器發送的，屬於TLS handshake，通常也和Server Hello與Certificate在一個TCP報文中。服務器將本身的公鑰參數傳輸給了客戶端，由於使用的是ECDHE，這裏傳輸的內容有：橢圓曲線域參數，以及公鑰的值。
• 這個就是密鑰交換協議的一部分，最終協商出密鑰來。

7. Server Hello Done

• 服務器發送的，屬於TLS handshake，通常也和Server Hello、Certificate和Server Key Exchange在一個TCP報文中，介於Server Hello和Server Hello之間的是服務器想要給客戶端的東西。因此這裏面客戶端沒有發送Client Hello Done

8. Client Key Exchange

• 客戶端發送的，屬於TLS handshake，客戶端收到了服務器的證書進行驗證，若是驗證經過了，就會繼續密鑰交換的過程，向服務器發送本身的公鑰參數。待服務器收到以後進行數學計算，就能夠協商出密鑰了，這裏客戶端實際上已經計算出了密鑰。

9. Change Cipher Spec

• 客戶端或者服務器發送的，屬於TLS handshake，緊跟着Key Exchange發送，表明本身生成了新的密鑰，通知對方之後將更換密鑰，使用新的密鑰進行通訊。

10. Encrypted Handshake Message

• 客戶端或者服務器發送的，屬於TLS handshake，也是緊跟着Key Exchange發送。這裏是進行一下測試，一方用本身的剛剛生成的密鑰加密一段固定的消息發送給對方，若是密鑰協商正確無誤的話，對方應該能夠解密。這段加密內容的明文通常是協議中規定好的，雙方都知道。

11. New Session Ticket

• 服務器發送的，屬於TLS handshake，服務器給客戶端一個會話，用處就是在一段時間以內（超時時間到來以前），雙方都以剛剛交換的密鑰進行通訊。從這之後，加密通訊正式開始。

12. Application Data

• 應用層的數據，是加密的，使用密鑰交換協議協商出來的密鑰加密。由於咱們的Wireshark不知道服務器的私鑰，因此這段通訊是安全的，咱們在Wireshark中也沒法解密這段信息。

13. Encrypted Alert

• 客戶端或服務器發送的，意味着加密通訊由於某些緣由須要中斷，警告對方不要再發送敏感的數據。

0x04 總結

• 本文粗略的介紹了TLS協議的1.2版本的通訊過程，重點是handshake的過程，以上部分完成了證書認證、密鑰協商以及加密傳輸的任務。
• 在我看來，計算機網絡有一種獨特的魅力，那就是人們在設計網絡協議的時候，也徹底是按照人類的思惟進行的設計。實際上在各類各樣的網絡協議中，到處流淌着人類的思想，體現着人類的文化。就好比本文介紹的TLS，就好像服務器和客戶端是兩我的在對話同樣。事實就是如此，計算機網絡就是計算機之間「對話」的科學。這也是我對計算機網絡的興趣所在。