http://blog.csdn.net/sdulibh/article/details/51627992
2015
作者：drinkey
以前讀RFC時總結的一篇文章，主要介紹了SSL/TLS協(xié)議的相關知識，包括協(xié)議本身以及簡單的密碼學概念，以及用實例解析了HTTP over SSL的協(xié)商過程，在最后簡要列出了SSL的安全問題。
RFC-2246: The TLS Protocol Version 1.0
詳細講述了TLS1.0的協(xié)議，TLS協(xié)議提供了一種Internet安全通信方式，該協(xié)議允許客戶端和服務端通信，并保證消息不被監(jiān)聽，篡改和偽造。
描述了如何使用TLS協(xié)議來保證HTTP通信的安全性
RFC-3749: Transport Layer Security Protocol Compression Methods
描述了TLS壓縮的幾種方式
RFC-5216: The EAP-TLS Authentication Protocol
EAP-TLS認證協(xié)議
RFC-5246: The Transport Layer Security (TLS) Protocol Version 1.2
TLS1.2協(xié)議文檔，在RFC2246基礎上有所發(fā)展
最初SSL協(xié)議是由netscape開發(fā)，并集成到瀏覽器中，用于保護HTTP傳輸安全性，作為在傳輸層和應用層之間的一層，對更多的需要保護數(shù)據(jù)安全性的協(xié)議進行封裝。IETF以SSL協(xié)議為基礎，提出了一種新的協(xié)議：TLS，建立在SSL V3.0的基礎上，是SSL 3.0的后續(xù)版本，已經(jīng)開始在實際應用中使用。
雖然TLS和SSL不能互操作，僅僅是因為他們使用的加密算法和MAC算法不同，協(xié)議本身差別非常細微。RFC-2246是IETF提出的第一個版本，被稱作TLS v1.0，目前最新的版本是TLS v1.2，在RFC-5246中描述了其細節(jié)問題。
以下根據(jù)RFC5246，介紹SSL
協(xié)議由兩層構成：TLS Record Protocol和TLS Handshake Protocol。
TLS Record Protocol處于較低的一層，基于一些可信任的協(xié)議，如TCP，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。它保證了通信的兩個基本安全屬性：
1．保密連接。數(shù)據(jù)傳輸使用對稱加密算法，如AES，RC4等，該對稱加密算法的密鑰對于每個連接是唯一的，基于密鑰協(xié)商協(xié)議生成，比如TLS handshake protocol，Record Protocol也可以不使用加密。
2．可信連接。消息的傳輸包括了基于密鑰的消息認證碼（keyed MAC），使用安全Hash函數(shù)計算MAC，用于完整性檢查。Record Protocol也可以不使用MAC，但是這種模式只用于安全參數(shù)協(xié)商時。
Record Protocol用于封裝多種高層的協(xié)議，其中一個種就是TLS handshake protocol，這種協(xié)議允許客戶與服務器相互認證，在應用程序通信前，協(xié)商加密算法和加密密鑰。TLS handshake protocol保證了連接的三個基本安全屬性：
TLS協(xié)議提供的服務主要有：
TLS協(xié)議在協(xié)議棧中如下圖所示：
TLS協(xié)議對數(shù)據(jù)的封裝如下圖所示：
為了便于更好的認識和理解SSL協(xié)議，這里著重介紹SSL協(xié)議的握手協(xié)議，mail.qq.com支持SSL協(xié)議，以下結合實例，介紹SSL握手協(xié)議。數(shù)據(jù)包使用Wireshark抓取。對于文中提到的密碼學術語，在文章第5節(jié)有簡單解釋，可對照閱讀。
SSL 協(xié)議既用到了非對稱公鑰加密技術又用到了對稱加密技術，對稱加密技術使用于Record層，用于對傳輸?shù)臄?shù)據(jù)進行加密，公鑰加密技術使用于Handshake協(xié)議，提供了身份認證的功能。
SSL 的握手協(xié)議非常有效的讓客戶和服務器之間完成相互之間的身份認證，本實例中只有客戶端驗證服務端，服務端并沒有對客戶端進行驗證，一般相互進行身份認證的情況在登錄銀行系統(tǒng)時會用到。
下面根據(jù)抓取到的數(shù)據(jù)包，分析瀏覽器訪問mail.qq.com時使用SSL協(xié)議的過程：
Cipher Specs字段是一個枚舉類型，說明了客戶端所支持算法，每個Cipher Spec指定了一個加密組合，從下圖可以看出，SSL與TLS的很顯著的區(qū)別就是，TLS支持了更多更先進更安全的加密組合，如下圖所示：
Random是服務端產(chǎn)生的隨機數(shù)，根據(jù)一個隨機種子生成，這里的隨機種子是gmt_unix_time，根據(jù)這個時間，使用偽隨機數(shù)函數(shù)（PRF）生成一個32字節(jié)的random_bytes。
Session ID是一組任意字節(jié)數(shù)的序列，由server選出，用于識別連接是活動狀態(tài)還是可恢復狀態(tài)。
Cipher Suite指定了服務端選定的加密組合，這里選出的加密組合是TLS_RSA_WITH_AES_256_CBC_SHA，RSA作為認證算法，256位的AES分組加密算法作為Record層加密payload使用的算法，SHA作為消息認證碼算法，用于保證消息的完整性，防止消息被篡改。
Compress Method表明了使用的壓縮算法，Record層接收高層協(xié)議的數(shù)據(jù)時，會將數(shù)據(jù)進行分片，前面已經(jīng)提到過，對于每個分片可以選擇使用一定壓縮算法來提高加密和傳輸效率，這里沒有使用壓縮算法，所以是null。
接著，服務端返回了證書，證書使用x.509格式，供客戶端驗證其身份，同時發(fā)送一個Server Hello Done消息。如下圖所示：
③客戶利用服務器傳過來的信息驗證服務器的合法性，服務器的合法性包括：證書是否過期，發(fā)行服務器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務器證書的“發(fā)行者的數(shù)字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續(xù)進行第四步。
④用戶端隨機產(chǎn)生一個用于后面通訊的密鑰，然后用服務器的公鑰（服務器的公鑰從步驟②中的服務器的證書中獲得）對其加密，然后將加密后的“預主密鑰”傳給服務器（Client key exchange）。該過程內容如下圖所示：
由于預主密鑰的傳輸使用RSA進行了加密，所以無法在抓取的數(shù)據(jù)包中顯示出來（在上圖中的Encrypted Handshake Message），從而保證了握手過程的保密性。
⑤如果服務端要求客戶的身份認證（在握手過程中為可選，本例中沒有該步驟），用戶可以建立一個隨機數(shù)然后對其進行數(shù)據(jù)簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書以及加密過的預主密碼（Premaster secret）一起傳給服務端。
⑥如果服務端要求客戶的身份認證，服務端必須檢驗客戶證書和簽名隨機數(shù)的合法性，具體的合法性驗證過程包括：客戶的證書使用日期是否有效，為客戶提供證書的CA 是否可靠，發(fā)行CA 的公鑰能否正確解開客戶證書的發(fā)行 CA 的數(shù)字簽名，檢查客戶的證書是否在證書廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，服務端將用自己的私鑰解開加密的預主密碼，然后執(zhí)行一系列步驟來產(chǎn)生主密鑰（Master secret）（客戶端也將通過同樣的方法產(chǎn)生相同的主通訊密碼）。
如果服務端沒有進行步驟5，服務端端收到客戶端發(fā)送的使用服務端公鑰加密的預主密鑰，用私鑰解開加密的預主密鑰，執(zhí)行一系列函數(shù)，生成會話的主密鑰，客戶端也進行相同的操作生成主密鑰。
⑦服務器和客戶端擁有了相同的主密鑰，雙方使用之前協(xié)商的對稱加密算法，并使用主密鑰作為密鑰，用于 SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時在 SSL 通訊過程中還要維護數(shù)據(jù)通信的完整性，防止數(shù)據(jù)通訊中的任何變化，通過消息認證碼來保證。
⑧客戶端向服務器端發(fā)出信息（Change cipher spec），指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知服務器客戶端的握手過程結束。
⑨服務器向客戶端發(fā)出信息（Change Cipher Spec），指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知客戶端服務器端的握手過程結束。
⑩SSL 的握手部分結束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務器開始使用相同的對稱密鑰進行數(shù)據(jù)通訊，同時進行通訊完整性的檢驗。該過程的數(shù)據(jù)包如下圖所示：
從此過程開始，TLS Record層使用Application Data Protocol通信，其Content-type字段變?yōu)镠TTP，這個字段記錄了上層協(xié)議的協(xié)議類型，以便數(shù)據(jù)提交到對方的TLS Record層后，對數(shù)據(jù)進行組裝，并交付給上層協(xié)議處理。
以上詳細闡述了基于TLS的HTTP協(xié)議（HTTPS）客戶端與服務端建立連接和握手的過程，以下對一些用到的密碼知識作為補充，進行簡單的介紹：
PRF：偽隨機數(shù)生成函數(shù)，用于生成任意大小的隨機序列。一般使用時間作為初始化的隨機種子，通過PRF生成隨機序列，如果序列的長度不符合要求，則使用Hash函數(shù)對序列進行散列運算，經(jīng)過幾輪迭代知道序列長度滿足要求為止。一個好的PRF可以保證序列的隨機性最大化，防止猜測。
對稱加密算法：如AES，DES，RC4。加密和解密的兩個過程使用相同的密鑰，通過加密和解密函數(shù)對數(shù)據(jù)進行操作，從而達到加密數(shù)據(jù)和解密數(shù)據(jù)的目的。
公鑰加密算法：如DSA，RSA。通信雙方共享各自的公鑰，傳輸時使用對方的公鑰對數(shù)據(jù)進行加密，接收方收到后，用自己的私鑰對數(shù)據(jù)進行解密。公鑰加密算法也被稱為非對稱加密算法，因為加密和解密使用不同的密鑰。公鑰算法的數(shù)學依據(jù)是大素數(shù)的分解問題，理論上很難分解一個足夠大素數(shù)。常做認證和簽字用。
分組密碼：很多對稱加密算法都是分組加密，先將需要加密的數(shù)據(jù)進行分組和填充，再將每個分組使用加密函數(shù)進行加密，經(jīng)過一些置換和迭代，得到固定長度的輸出。
Hash函數(shù)：如SHA，MD5。散列函數(shù)，具有單向性。散列函數(shù)對消息進行摘要，并經(jīng)過迭代，得到固定長度的輸出。消息的一個字節(jié)的變化對Hash函數(shù)的輸出都會有很大的影響。
MAC：消息認證碼，由Hash函數(shù)對消息進行摘要得到，由于Hash函數(shù)的特性，可以提供對消息完整性的驗證，一般隨消息一起發(fā)出。
TLS協(xié)議大量的使用了以上密碼算法，從而保證了數(shù)據(jù)的完整性和保密性，密碼學是TLS協(xié)議安全的基礎，任何一種使用到的密碼算法被破解，將直接影響TLS協(xié)議的安全性。
TLS協(xié)議并不是牢不可破的，使用了TLS的HTTP協(xié)議不一定安全。由于TLS協(xié)議中有很多可選項，甚至可以選擇Record層是否使用加密，如果沒有很好的配置，那么TLS也不能保證傳輸?shù)陌踩浴?/p>
2009 blackhat con中Marsh Ray提到了Renegotiating TLS attack，由于TLS renegotiating的邏輯漏洞，造成在理想環(huán)境下，可以實施中間人攻擊，這個攻擊是非常巧妙的，主要是利用了TLS/SSL 3.0重置加密算法機制和HTTP協(xié)議請求頭的key、value結構，實現(xiàn)了多次數(shù)據(jù)的組合以完成自己想要的請求。
主要步驟如下：
1). 攻擊者連接目標站點完成SSL握手稱為session 1，并發(fā)送GET /adduser.jsp?u=test&passwd=123 HTTP/1.1\r\nFVCK: 之類的數(shù)據(jù)包。
2). 攻擊者劫持被攻擊者訪問目標站點的數(shù)據(jù)，在session 1中轉發(fā)被攻擊者與目標服務器之間的SSL握手，被攻擊者和目標服務器完成握手稱為session 2。
3). 目標站點和被攻擊者通過攻擊者的轉發(fā)完成握手，在session 2中被攻擊者發(fā)送自己的請求數(shù)據(jù)到目標服務器，類似于GET / HTTP/1.1\r\nHost: www.xxx.com\r\nAccept: */*\r\nCookie: admin=1\r\n\r\n之類的數(shù)據(jù)。
4). 目標站點在一個SSL Session 1中接收到一個新的SSL Client Hello時，會認為客戶端是在要求重新生成密鑰，因為在目標服務器看來session 2也是攻擊者發(fā)過來的，而且是相同的TCP session中。最終導致目標服務器認為session 2是session 1密鑰重置之后的延續(xù)，會將兩次的數(shù)據(jù)組合到一起。
5). 最終數(shù)據(jù)如下：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字段的值，一起被忽略掉，攻擊者成功的執(zhí)行了添加WEB系統(tǒng)用戶的操作
詳細介紹參照Marsh Ray的原作：
http://extendedsubset.com/Renegotiating_TLS.pdf
文檔的最后展示了中間人攻擊的結果，成功獲得了TLS協(xié)議上層協(xié)議的內容。
2014年Google公布了SSLv3的漏洞，CVE--2014-3566，代號POODLE(Padding Oracle On Downgraded Legacy Encryption)，目前只有通過服務端禁用SSLv3.0協(xié)議來防止此攻擊的發(fā)生。
知名的開源安全軟件OpenSSL同樣在2014年同樣也爆出了Heart bleed漏洞，造成攻擊者可以直接讀取內存中的數(shù)據(jù)。
