SSL/TLS 協議簡介與實例分析

作者：drinkey

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

1. RFC documents about SSL/TLS

RFC-2246: The TLS Protocol Version 1.0

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

RFC-2818: HTTP Over TLS

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

RFC-3749: Transport Layer Security Protocol Compression Methods

描述了TLS壓縮的幾種方式

RFC-5216: The EAP-TLS Authentication Protocol

EAP-TLS認證協議

RFC-5246: The Transport Layer Security (TLS) Protocol Version 1.2

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的原作：

http://extendedsubset.com/Renegotiating_TLS.pdf

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

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

知名的開源安全軟件OpenSSL同樣在2014年同樣也爆出了Heart bleed漏洞，造成攻擊者可以直接讀取內存中的數據。