來源：http://blog.catchpoint.com/2017/05/12/dissecting-tls-using-wireshark/
RFC 2246 (TLS version 1.0)中定義的傳輸層安全協(xié)議的主要目標是“在兩個通信應(yīng)用程序之間提供隱私和數(shù)據(jù)完整性”?！癟LS協(xié)議通過加密數(shù)據(jù)來確保這一點，因此任何第三方都無法攔截通信;它還對對等點進行身份驗證，以驗證它們的身份。通過在兩個對等點之間提供一個安全的通信通道，TLS協(xié)議保護了消息的完整性，并確保消息沒有被篡改。
一、歷史
TLS和SSL可以互換使用。從SSL協(xié)議(SSL 3.0)發(fā)展而來的TLS不再被認為是安全的;貴賓犬攻擊等漏洞已經(jīng)證明了這一點。TLS經(jīng)過了兩個迭代，RFC 4346 (TLS 1.1)和RFC 5246 (TLS 1.2)，最新的更新TLS 1.3是一個工作草案。
二、架構(gòu)
TLS位于應(yīng)用程序和傳輸層之間。它的設(shè)計工作在可靠的傳輸協(xié)議，如TCP(但已適應(yīng)UDP，以及)，并分為兩個子層:
1、TCP記錄協(xié)議層-這是位于TCP層之上的較低層，負責:
（1）將要傳輸?shù)南⒎指畛煽晒芾淼膲K；
（2）加密/解密散列數(shù)據(jù)；
（3）壓縮/解壓輸出/輸入數(shù)據(jù)；
（4）應(yīng)用消息驗證碼(MAC)，一個散列來維護數(shù)據(jù)完整性；
（5）將數(shù)據(jù)從上層應(yīng)用層傳輸?shù)较聦觽鬏攲?，反之亦然?/p>
2、上層由以下子協(xié)議組成:
（1）告警:此子協(xié)議定義告警級別并提供告警的描述。它用于將發(fā)生的任何錯誤情況通知對等方。
（2）更改密碼規(guī)范:它定義了加密策略中的更改。由客戶機和服務(wù)器傳輸?shù)母拿艽a規(guī)范消息定義了重新協(xié)商的密碼規(guī)范和密鑰，這些密鑰將用于以后交換的所有消息。
（3）應(yīng)用程序數(shù)據(jù):此協(xié)議確保以安全的方式對消息進行分段、壓縮、加密和傳輸。
（4）握手:要在安全通道上通信，兩個對等方必須就該會話的加密密鑰和加密算法達成一致。TLS協(xié)議描述了對對等點進行身份驗證并使用定義的參數(shù)建立安全連接的步驟。包括設(shè)置會話標識符、TLS協(xié)議版本、協(xié)商密碼套件、對等點的證書認證和對等點之間的密鑰交換的整個序列稱為TLS握手。TLS握手的步驟如下:
3、使用Wireshark分析TLS握手
下圖是使用Wireshark(一種流行的網(wǎng)絡(luò)協(xié)議分析工具)捕獲的客戶機和服務(wù)器之間TLS握手的快照。
讓我們分析每一步。
（1）初始客戶端到服務(wù)器通信
Client Hello
通常，TLS握手中的第一條消息是客戶機hello消息，客戶機發(fā)送該消息來啟動與服務(wù)器的會話。
消息包含:
a、版本:客戶端希望用于與服務(wù)器通信的TLS協(xié)議版本號。這是客戶端支持的最高版本。
b、客戶端隨機:一個32字節(jié)的偽隨機數(shù)，用于計算主密鑰(用于創(chuàng)建加密密鑰)。
c、會話標識符:客戶端用來標識會話的唯一數(shù)字。
d、密碼套件:客戶機支持的密碼套件列表，按客戶機的首選項排序。密碼組由密鑰交換算法、批量加密算法、MAC算法和偽隨機函數(shù)組成。單一密碼套件(上圖中提到的28個套件之一)的例子如下:
其中，
TLS = 協(xié)議版本
RSA =確定對等認證的密鑰交換算法
3 des_ede_cbc =批量加密算法用于數(shù)據(jù)加密
SHA-1 =消息身份驗證代碼，這是一個加密散列。
e、壓縮方法:包含按客戶端首選項排序的壓縮算法列表。這是可選的。
（2）服務(wù)器對客戶機的響應(yīng)
服務(wù)器用多條消息響應(yīng)客戶端:
Server Hello
服務(wù)器Hello包含以下信息:
a、服務(wù)器版本:服務(wù)器支持的最高TLS協(xié)議版本，客戶端也支持。
b、服務(wù)器隨機:32字節(jié)的偽隨機數(shù)，用于生成主密鑰。
c、會話標識符:標識與客戶端對應(yīng)連接的會話的惟一編號。
如果客戶機hello消息中的會話ID不是空的，服務(wù)器將在會話緩存中找到匹配的會話ID。如果找到匹配項，并且服務(wù)器希望使用相同的會話狀態(tài)，它將返回客戶機發(fā)送的相同ID。如果服務(wù)器不想恢復(fù)相同的會話，則生成一個新ID。服務(wù)器還可以發(fā)送一個空ID，指示會話無法恢復(fù)。
d、密碼套件:服務(wù)器和客戶端都支持的最強大的密碼套件。如果不支持密碼套件，則會創(chuàng)建握手失敗警報。
e、壓縮方法:服務(wù)器和客戶端一致同意的壓縮算法。這是可選的。
Server Certificate
服務(wù)器向客戶機發(fā)送一個X.509證書列表，以便對自己進行身份驗證。服務(wù)器的證書包含其公鑰。此證書身份驗證要么由受對等點、操作系統(tǒng)和瀏覽器信任的第三方(證書頒發(fā)機構(gòu))執(zhí)行，其中包含已知證書頒發(fā)機構(gòu)的列表，要么通過手動導(dǎo)入用戶信任的證書。
Certificate Status
此消息驗證服務(wù)器的X.509數(shù)字證書是否被撤銷，通過與指定的OCSP(在線證書狀態(tài)協(xié)議)服務(wù)器聯(lián)系來確定。OCSP響應(yīng)的日期和簽名包含證書狀態(tài)?？蛻舳丝梢哉埱蠓?wù)器發(fā)送包含OCSP響應(yīng)的“證書狀態(tài)”消息。這種方法稱為OCSP裝訂。該過程可以在受限的網(wǎng)絡(luò)上節(jié)省帶寬，因為它可以防止OCSP服務(wù)器被過多的客戶機請求淹沒。
為了表示它需要一個證書狀態(tài)消息，客戶機在客戶機Hello請求中包含一個類型為“status_request”的擴展。
Server Key Exchange
該消息是可選的，當服務(wù)器證書中的公鑰不適合密鑰交換時，或者如果密碼套件設(shè)置了需要臨時密鑰的限制，則發(fā)送該消息?？蛻舳松院髮⑹褂么嗣荑€加密客戶端密鑰交換。
Client Certificate Request
這是可選的，當服務(wù)器要對客戶端進行身份驗證時發(fā)送，例如，在提供對私有信息的訪問之前，服務(wù)器需要確認客戶端的身份。該消息包含所需的證書類型和可接受的證書頒發(fā)機構(gòu)列表。
Server Hello Done
此消息指示服務(wù)器已經(jīng)完成，正在等待客戶機的響應(yīng)。
（3）客戶機對服務(wù)器的響應(yīng)
Client Key Exchange
這個消息包含:
a、客戶機的協(xié)議版本，服務(wù)器將驗證它是否與原始客戶機hello消息匹配。
b、Pre-master 秘鑰—由客戶機生成并使用服務(wù)器公鑰加密的隨機數(shù)。這連同客戶機和服務(wù)器隨機數(shù)一起用于創(chuàng)建主機密。如果服務(wù)器能夠使用私鑰解密消息，并且能夠在本地創(chuàng)建主機密，那么客戶端就可以確信服務(wù)器已經(jīng)對自己進行了身份驗證。
Change Cipher Spec
此消息通知服務(wù)器，所有未來的消息都將使用剛才協(xié)商的算法和密鑰進行加密。
Finished (Encrypted Handshake)
完成的消息比較復(fù)雜，因為它是以前交換的所有消息的散列，以及一個標簽(“client Finished”)。此消息表明，已為客戶機完成了TLS協(xié)商。
注意:Wireshark將完成的消息顯示為加密握手，因為與之前的消息不同，此消息是用剛剛協(xié)商好的密鑰/算法加密的。
（4）服務(wù)器對客戶機的響應(yīng)
Change Cipher Spec
服務(wù)器通知客戶機，它將使用現(xiàn)有的算法和密鑰對消息進行加密。現(xiàn)在，記錄層將其狀態(tài)更改為使用對稱密鑰加密。
Finished
與客戶端已完成的消息類似，但包含不同的標簽(“服務(wù)器已完成”)。一旦客戶機成功解密并驗證了消息，服務(wù)器就成功地通過了身份驗證。
（5）應(yīng)用程序數(shù)據(jù)流
一旦整個TLS握手成功完成，并且對等點經(jīng)過驗證，對等點上的應(yīng)用程序就可以開始彼此通信了。
本文簡要說明了TLS協(xié)議的工作原理，并使用Wireshark等功能強大的工具分析了TLS握手。需要注意的一件重要事情是，應(yīng)用程序不應(yīng)該依賴TLS在對等點之間創(chuàng)建最強的安全連接，因為黑客可能會使對等點下降到最不安全的連接。此外，使用TSL/SSL可能會影響性能(在這里解釋)。因此，對協(xié)議的清晰理解將有助于評估其優(yōu)點和弱點。
我們將在接下來的博客中探討TLS的性能和可用性挑戰(zhàn)。
