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