作者：drinkey

以前讀RFC時總結的一篇文章，主要介紹了SSL/TLS協議的相關知識，包括協議本身以及簡單的密碼學概念，以及用例項解析了HTTP over SSL的協商過程，在最後簡要列出了SSL的安全問題。

1. RFC documents about SSL/TLS

詳細講述了TLS1.0的協議，TLS協議提供了一種Internet安全通訊方式，該協議允許客戶端和服務端通訊，並保證訊息不被監聽，篡改和偽造。

描述瞭如何使用TLS協議來保證HTTP通訊的安全性

描述了TLS壓縮的幾種方式

EAP-TLS認證協議

TLS1.2協議文件，在RFC2246基礎上有所發展

2. SSL/TLS簡介

最初SSL協議是由netscape開發，並整合到瀏覽器中，用於保護HTTP傳輸安全性，作為在傳輸層和應用層之間的一層，對更多的需要保護資料安全性的協議進行封裝。IETF以SSL協議為基礎，提出了一種新的協議：TLS，建立在SSL V3.0的基礎上，是SSL 3.0的後續版本，已經開始在實際應用中使用。

雖然TLS和SSL不能互操作，僅僅是因為他們使用的加密演算法和MAC演算法不同，協議本身差別非常細微。RFC-2246是IETF提出的第一個版本，被稱作TLS v1.0，目前最新的版本是TLS v1.2，在RFC-5246中描述了其細節問題。

以下根據RFC5246，介紹SSL

3. SSL協議組成

協議由兩層構成：TLS Record Protocol和TLS Handshake Protocol。

TLS Record Protocol處於較低的一層，基於一些可信任的協議，如TCP，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。它保證了通訊的兩個基本安全屬性：

• 1．保密連線。資料傳輸使用對稱加密演算法，如AES，RC4等，該對稱加密演算法的金鑰對於每個連線是唯一的，基於金鑰協商協議生成，比如TLS handshake protocol，Record Protocol也可以不使用加密。

• 2．可信連線。訊息的傳輸包括了基於金鑰的訊息認證碼（keyed MAC），使用安全Hash函式計算MAC，用於完整性檢查。Record Protocol

  也可以不使用MAC，但是這種模式只用於安全引數協商時。

Record Protocol用於封裝多種高層的協議，其中一個種就是TLS handshake protocol，這種協議允許客戶與伺服器相互認證，在應用程式通訊前，協商加密演算法和加密金鑰。TLS handshake protocol保證了連線的三個基本安全屬性：

• 1．兩端的身份可以通過非對稱或者公鑰加密演算法（DSA，RSA等）進行認證。認證過程是可選的，但至少要求一端被認證。 
• 2．共享金鑰的協商是安全的。金鑰協商對於監聽者和任何被認證的連線都是不可見的。 
• 3．協商是可信的。攻擊者無法修改協商資訊。

TLS協議提供的服務主要有：

• 1）認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器；
• 2）加密資料以防止資料中途被攻擊者監聽；
• 3）維護資料的完整性，確保資料在傳輸過程中不被攻擊者篡改。 

TLS協議在協議棧中如下圖所示：

TLS協議對資料的封裝如下圖所示：

4. HTTP over SSL例項分析

為了便於更好的認識和理解SSL協議，這裡著重介紹SSL協議的握手協議，mail.qq.com支援SSL協議，以下結合例項，介紹SSL握手協議。資料包使用Wireshark抓取。對於文中提到的密碼學術語，在文章第5節有簡單解釋，可對照閱讀。

SSL 協議既用到了非對稱公鑰加密技術又用到了對稱加密技術，對稱加密技術使用於Record層，用於對傳輸的資料進行加密，公鑰加密技術使用於Handshake協議，提供了身份認證的功能。

SSL 的握手協議非常有效的讓客戶和伺服器之間完成相互之間的身份認證，本例項中只有客戶端驗證服務端，服務端並沒有對客戶端進行驗證，一般相互進行身份認證的情況在登入銀行系統時會用到。

下面根據抓取到的資料包，分析瀏覽器訪問mail.qq.com時使用SSL協議的過程：

• ①客戶端的瀏覽器向伺服器提出TCP連線請求，建立起TCP連線後，客戶端向服務端傳送Client Hello訊息，傳送客戶端 SSL 協議的版本號，加密演算法的種類，以及其他伺服器和客戶端之間通訊所需要的各種資訊。Client Hello訊息的內容如下圖所示：

Cipher Specs欄位是一個列舉型別，說明了客戶端所支援演算法，每個Cipher Spec指定了一個加密組合，從下圖可以看出，SSL與TLS的很顯著的區別就是，TLS支援了更多更先進更安全的加密組合，如下圖所示：

• ②服務端收到建立SSL連線的請求後，向客戶端傳送 SSL 協議的版本號，加密演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向客戶端傳送自己的證書。如下圖所示：

Random是服務端產生的隨機數，根據一個隨機種子生成，這裡的隨機種子是gmt_unix_time，根據這個時間，使用偽隨機數函式（PRF）生成一個32位元組的random_bytes。

Session ID是一組任意位元組數的序列，由server選出，用於識別連線是活動狀態還是可恢復狀態。

Cipher Suite指定了服務端選定的加密組合，這裡選出的加密組合是TLS_RSA_WITH_AES_256_CBC_SHA，RSA作為認證演算法，256位的AES分組加密演算法作為Record層加密payload使用的演算法，SHA作為訊息認證碼演算法，用於保證訊息的完整性，防止訊息被篡改。

Compress Method表明了使用的壓縮演算法，Record層接收高層協議的資料時，會將資料進行分片，前面已經提到過，對於每個分片可以選擇使用一定壓縮演算法來提高加密和傳輸效率，這裡沒有使用壓縮演算法，所以是null。

接著，服務端返回了證書，證書使用x.509格式，供客戶端驗證其身份，同時傳送一個Server Hello Done訊息。如下圖所示：

• ③客戶利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：證書是否過期，發行伺服器證書的 CA 是否可靠，發行者證書的公鑰能否正確解開伺服器證書的“發行者的數字簽名”，伺服器證書上的域名是否和伺服器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。

• ④使用者端隨機產生一個用於後面通訊的金鑰，然後用伺服器的公鑰（伺服器的公鑰從步驟②中的伺服器的證書中獲得）對其加密，然後將加密後的“預主金鑰”傳給伺服器（Client key exchange）。該過程內容如下圖所示：

由於預主金鑰的傳輸使用RSA進行了加密，所以無法在抓取的資料包中顯示出來（在上圖中的Encrypted Handshake Message），從而保證了握手過程的保密性。

• ⑤如果服務端要求客戶的身份認證（在握手過程中為可選，本例中沒有該步驟），使用者可以建立一個隨機數然後對其進行資料簽名，將這個含有簽名的隨機數和客戶自己的證書以及加密過的預主密碼（Premaster secret）一起傳給服務端。

• ⑥如果服務端要求客戶的身份認證，服務端必須檢驗客戶證書和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發行CA 的公鑰能否正確解開客戶證書的發行 CA 的數字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務端將用自己的私鑰解開加密的預主密碼，然後執行一系列步驟來產生主金鑰（Master secret）（客戶端也將通過同樣的方法產生相同的主通訊密碼）。

  如果服務端沒有進行步驟5，服務端端收到客戶端傳送的使用服務端公鑰加密的預主金鑰，用私鑰解開加密的預主金鑰，執行一系列函式，生成會話的主金鑰，客戶端也進行相同的操作生成主金鑰。

• ⑦伺服器和客戶端擁有了相同的主金鑰，雙方使用之前協商的對稱加密演算法，並使用主金鑰作為金鑰，用於 SSL 協議的安全資料通訊的加解密通訊。同時在 SSL 通訊過程中還要維護資料通訊的完整性，防止資料通訊中的任何變化，通過訊息認證碼來保證。

• ⑧客戶端向伺服器端發出資訊（Change cipher spec），指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知伺服器客戶端的握手過程結束。

• ⑨伺服器向客戶端發出資訊（Change Cipher Spec），指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知客戶端伺服器端的握手過程結束。

• ⑩SSL 的握手部分結束，SSL 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。該過程的資料包如下圖所示：

從此過程開始，TLS Record層使用Application Data Protocol通訊，其Content-type欄位變為HTTP，這個欄位記錄了上層協議的協議型別，以便資料提交到對方的TLS Record層後，對資料進行組裝，並交付給上層協議處理。

5. 密碼學知識簡單介紹

以上詳細闡述了基於TLS的HTTP協議（HTTPS）客戶端與服務端建立連線和握手的過程，以下對一些用到的密碼知識作為補充，進行簡單的介紹：

PRF：偽隨機數生成函式，用於生成任意大小的隨機序列。一般使用時間作為初始化的隨機種子，通過PRF生成隨機序列，如果序列的長度不符合要求，則使用Hash函式對序列進行雜湊運算，經過幾輪迭代知道序列長度滿足要求為止。一個好的PRF可以保證序列的隨機性最大化，防止猜測。

對稱加密演算法：如AES，DES，RC4。加密和解密的兩個過程使用相同的金鑰，通過加密和解密函式對資料進行操作，從而達到加密資料和解密資料的目的。

公鑰加密演算法：如DSA，RSA。通訊雙方共享各自的公鑰，傳輸時使用對方的公鑰對資料進行加密，接收方收到後，用自己的私鑰對資料進行解密。公鑰加密演算法也被稱為非對稱加密演算法，因為加密和解密使用不同的金鑰。公鑰演算法的數學依據是大素數的分解問題，理論上很難分解一個足夠大素數。常做認證和簽字用。

分組密碼：很多對稱加密演算法都是分組加密，先將需要加密的資料進行分組和填充，再將每個分組使用加密函式進行加密，經過一些置換和迭代，得到固定長度的輸出。

Hash函式：如SHA，MD5。雜湊函式，具有單向性。雜湊函式對訊息進行摘要，並經過迭代，得到固定長度的輸出。訊息的一個位元組的變化對Hash函式的輸出都會有很大的影響。

MAC：訊息認證碼，由Hash函式對訊息進行摘要得到，由於Hash函式的特性，可以提供對訊息完整性的驗證，一般隨訊息一起發出。

TLS協議大量的使用了以上密碼演算法，從而保證了資料的完整性和保密性，密碼學是TLS協議安全的基礎，任何一種使用到的密碼演算法被破解，將直接影響TLS協議的安全性。

6. SSL/TLS Security Issues

TLS協議並不是牢不可破的，使用了TLS的HTTP協議不一定安全。由於TLS協議中有很多可選項，甚至可以選擇Record層是否使用加密，如果沒有很好的配置，那麼TLS也不能保證傳輸的安全性。

2009 blackhat con中Marsh Ray提到了Renegotiating TLS attack，由於TLS renegotiating的邏輯漏洞，造成在理想環境下，可以實施中間人攻擊，這個攻擊是非常巧妙的，主要是利用了TLS/SSL 3.0重置加密演算法機制和HTTP協議請求頭的key、value結構，實現了多次資料的組合以完成自己想要的請求。

主要步驟如下：

• 1). 攻擊者連線目標站點完成SSL握手稱為session 1，併發送GET /adduser.jsp?u=test&passwd=123 HTTP/1.1\r\nFVCK: 之類的資料包。

• 2). 攻擊者劫持被攻擊者訪問目標站點的資料，在session 1中轉發被攻擊者與目標伺服器之間的SSL握手，被攻擊者和目標伺服器完成握手稱為session 2。

• 3). 目標站點和被攻擊者通過攻擊者的轉發完成握手，在session 2中被攻擊者傳送自己的請求資料到目標伺服器，類似於GET / HTTP/1.1\r\nHost: www.xxx.com\r\nAccept: */*\r\nCookie: admin=1\r\n\r\n之類的資料。

• 4). 目標站點在一個SSL Session 1中接收到一個新的SSL Client Hello時，會認為客戶端是在要求重新生成金鑰，因為在目標伺服器看來session 2也是攻擊者發過來的，而且是相同的TCP session中。最終導致目標伺服器認為session 2是session 1金鑰重置之後的延續，會將兩次的資料組合到一起。

• 5). 最終資料如下：GET /adduser.jsp?u=test&passwd=123 HTTP/1.1\r\nFVCK: GET / HTTP/1.1\r\nHost: www.xxx.com\r\nAccept: */*\r\nCookie: admin=1\r\n\r\n。FVCK欄位伺服器不認識，真實請求GET / HTTP/1.1當成了FVCK欄位的值，一起被忽略掉，攻擊者成功的執行了新增WEB系統使用者的操作

詳細介紹參照Marsh Ray的原作：

文件的最後展示了中間人攻擊的結果，成功獲得了TLS協議上層協議的內容。

2014年Google公佈了SSLv3的漏洞，CVE­-2014-3566，代號POODLE(Padding Oracle On Downgraded Legacy Encryption)，目前只有通過服務端禁用SSLv3.0協議來防止此攻擊的發生。

知名的開源安全軟體OpenSSL同樣在2014年同樣也爆出了Heart bleed漏洞，造成攻擊者可以直接讀取記憶體中的資料。