網(wǎng)絡(luò)安全與保密（第二版）課件：SSL和TLS

SSL和TLS7.1SSL協(xié)議體系結(jié)構(gòu)7.2SSL/TLS記錄協(xié)議7.3改變密碼規(guī)范協(xié)議7.4告警協(xié)議7.5握手協(xié)議7.6密鑰計(jì)算參考文獻(xiàn)思考題

安全套接層協(xié)議(SecureSocketsLayer，SSL)是由網(wǎng)景(Netscape)公司于1994年開發(fā)的，用于提供互聯(lián)網(wǎng)交易安全的協(xié)議。其第一版協(xié)議內(nèi)容并沒有對(duì)外公開，協(xié)議的第二版SSL2.0在1994年晚些時(shí)候?qū)ν獍l(fā)布，并在其開發(fā)的瀏覽器上實(shí)現(xiàn)了該協(xié)議。

不幸的是，SSL2.0協(xié)議存在嚴(yán)重的安全問(wèn)題，特別是網(wǎng)景公司在該協(xié)議的實(shí)現(xiàn)上由于對(duì)偽隨機(jī)數(shù)發(fā)生器的處理不當(dāng)導(dǎo)致重大安全漏洞。

Goldberg和Wagner[1]發(fā)現(xiàn)：偽隨機(jī)數(shù)發(fā)生器的種子是由時(shí)間、UNIX系統(tǒng)進(jìn)程ID(pid)及其父進(jìn)程ID(ppid)計(jì)算得到的，因此，很大程度上減少了密鑰的猜測(cè)空間。如果攻擊者在運(yùn)行SSL服務(wù)程序的計(jì)算機(jī)上擁有賬戶的話，甚至可以獲得用戶的pid和ppid信息，從而可以在25秒內(nèi)恢復(fù)出密鑰。根據(jù)Rescorla的研究[2]，即便無(wú)法獲得pid和ppid，也可以在1小時(shí)內(nèi)恢復(fù)出密鑰。

所以，網(wǎng)景公司在1995年底發(fā)布了SSL3.0版本的協(xié)議規(guī)范，它基本上是SSL2.0的重寫，彌補(bǔ)了SSL2.0的安全缺陷，并增加了新的密碼組件，引入了新的報(bào)文消息。

1996年，互聯(lián)網(wǎng)工程任務(wù)組(IETF)以SSL3.0為基礎(chǔ)致力于SSL協(xié)議的標(biāo)準(zhǔn)化工作，在1999年發(fā)布了傳輸層安全(TransportLayerSecurity，TLS)協(xié)議標(biāo)準(zhǔn)，即2246。目前TLS的最新標(biāo)準(zhǔn)是TLS1.2，就是RFC5246，其內(nèi)容與SSLv3.3十分接近，只是在選擇認(rèn)證算法和實(shí)際的信息模式上有些差異。在此我們統(tǒng)一以SSL/TLS來(lái)表示這兩個(gè)協(xié)議，不同之處在文中將分別予以敘述。

目前主流瀏覽器和服務(wù)器都支持SSL/TLS協(xié)議，實(shí)現(xiàn)瀏覽器與服務(wù)器之間的身份認(rèn)證和加密數(shù)據(jù)傳輸。除此之外，SSL/TLS還可以用于其它應(yīng)用協(xié)議，如FTP，LDAP和SMTP。

7.1SSL協(xié)議體系結(jié)構(gòu)

SSL/TLS協(xié)議位于可靠的面向連接網(wǎng)絡(luò)層協(xié)議(即TCP/IP)和應(yīng)用層協(xié)議(如HTTP)之間，如圖7-1所示。它在客戶端和服務(wù)器之間提供安全通信：允許雙方互相認(rèn)證、使用消息的數(shù)字簽名來(lái)提供完整性、通過(guò)加密提供消息保密性。圖7-1SSL/TLS運(yùn)行于TCP/IP之上，高級(jí)應(yīng)用協(xié)議之下

SSL/TLS協(xié)議的優(yōu)勢(shì)在于它是與應(yīng)用層協(xié)議獨(dú)立無(wú)關(guān)的。高層的應(yīng)用層協(xié)議(例如：Http、FTP、Telnet等)能透明的建立于SSL/TLS協(xié)議之上。SSL/TLS協(xié)議在應(yīng)用層協(xié)議通信之前就已經(jīng)完成加密算法、通信密鑰的協(xié)商以及服務(wù)器認(rèn)證工作。在此之后應(yīng)用層協(xié)議所傳送的數(shù)據(jù)都會(huì)被加密，從而保證通信的私密性。

SSL/TLS協(xié)議位于TCP/IP協(xié)議與各種應(yīng)用層協(xié)議之間，由多個(gè)協(xié)議組成。SSL/TLS采用兩層協(xié)議體系結(jié)構(gòu)，如圖7-2所示。

圖7-2SSL/TLS協(xié)議棧

SSL/TLS協(xié)議分為兩層：SSL/TLS記錄協(xié)議(SSL/TLSRecordProtocol)—它建立在可靠的傳輸協(xié)議(如TCP)之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持；SSL/TLS握手協(xié)議(SSL/TLSHandshakeProtocol)—它建立在SSL/TLS記錄協(xié)議之上，用于在實(shí)際的數(shù)據(jù)傳輸開始前，通訊雙方進(jìn)行身份認(rèn)證、協(xié)商加密算法、交換加密密鑰等。

SSL/TLS協(xié)議提供的服務(wù)主要有：

(1)認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；

(2)加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊取；

(3)維護(hù)數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過(guò)程中不被改變。

SSL/TLS協(xié)議支持眾多加密、哈希和簽名算法，使得服務(wù)器在選擇算法時(shí)有很大的靈活性，這樣就可以根據(jù)以往的算法、進(jìn)出口限制或者最新開發(fā)的算法來(lái)進(jìn)行選擇。具體選擇什么樣的算法雙方可以在建立會(huì)話之初進(jìn)行協(xié)商。

SSL/TLS的兩個(gè)重要概念是SSL/TLS會(huì)話和SSL/TLS連接，具體定義如下：

(1)連接。連接是客戶服務(wù)器之間的邏輯鏈路，用于提供合適的傳輸服務(wù)和操作環(huán)境。連接是對(duì)等的，暫時(shí)的。每個(gè)連接都和一個(gè)會(huì)話相關(guān)。

(2)會(huì)話。會(huì)話是指客戶機(jī)和服務(wù)器之間的關(guān)聯(lián)。會(huì)話由SSL/TLS握手協(xié)議創(chuàng)建。會(huì)話定義了一組可以被多個(gè)連接共用的密碼安全參數(shù)。對(duì)于每個(gè)連接，可以利用會(huì)話來(lái)避免對(duì)新的安全參數(shù)進(jìn)行代價(jià)昂貴的協(xié)商。

在任意通信雙方之間，每個(gè)會(huì)話可以包含多個(gè)安全連接。參與通信的雙方實(shí)體也可以存在多個(gè)同時(shí)的會(huì)話。

一個(gè)SSL/TLS會(huì)話是有狀態(tài)(Stateful)的，由SSL/TLS握手協(xié)議負(fù)責(zé)協(xié)調(diào)客戶機(jī)和服務(wù)器之間的狀態(tài)。邏輯上有兩種狀態(tài)：當(dāng)前操作狀態(tài)和未決狀態(tài)(在握手協(xié)議期間)。此外，還需維持獨(dú)立的讀和寫狀態(tài)。當(dāng)客戶機(jī)或者服務(wù)器接收到改變碼規(guī)范消息，它就會(huì)拷貝未決讀狀態(tài)為當(dāng)前讀狀態(tài)。當(dāng)客戶機(jī)或者服務(wù)器發(fā)送一條改變密碼規(guī)范消息，它就會(huì)拷貝未決寫狀態(tài)為當(dāng)前寫狀態(tài)。當(dāng)握手協(xié)商完成，客戶機(jī)和服務(wù)器交換改變密碼規(guī)范消息，然后它們之間的后續(xù)通信采用新近達(dá)成的密碼規(guī)范進(jìn)行處理。

SSL/TLS握手協(xié)議用于確定下列安全參數(shù)：

(1)連接端點(diǎn)(ConnectionEnd)：作為客戶或者服務(wù)器的實(shí)體雙方。

(2)

PRF算法：用于從主密鑰產(chǎn)生密鑰的算法。

(3)分組加密算法：包括算法的密鑰長(zhǎng)度，是否分組還是流密碼或者AEAD密碼，密碼的分組長(zhǎng)度以及初始化向量的長(zhǎng)度。

(4)

MAC算法：消息認(rèn)證算法。

(5)壓縮算法：數(shù)據(jù)壓縮算法及壓縮算法所需要的所有信息。

(6)主密鑰：連接雙方實(shí)體共享的48字節(jié)密鑰。

(7)客戶機(jī)隨機(jī)數(shù)(Clientrandom)：客戶機(jī)為每個(gè)連接提供的32字節(jié)值。

(8)服務(wù)器隨機(jī)數(shù)(Serverrandom)：服務(wù)器為每個(gè)連接提供的32字節(jié)值。

而SSL/TLS記錄層將使用上述安全參數(shù)來(lái)初始化連接狀態(tài)，并生成以下六項(xiàng)同密鑰相關(guān)的參數(shù)：

(1)客戶機(jī)寫MAC密鑰(ClientwriteMACkey)：客戶機(jī)所寫數(shù)據(jù)的MAC操作密鑰。

(2)服務(wù)器寫MAC密鑰(ServerwriteMACkey)：服務(wù)器所寫數(shù)據(jù)的MAC操作密鑰。

(3)客戶機(jī)寫加密密鑰(Clientwriteencryptionkey)：客戶機(jī)加密數(shù)據(jù)和服務(wù)器解密數(shù)據(jù)的分組密碼密鑰。

(4)服務(wù)器寫加密密鑰(Serverwriteencryptionc)：服務(wù)器加密數(shù)據(jù)和客戶機(jī)解密數(shù)據(jù)的分組密碼密鑰。

(5)客戶機(jī)寫初始化向量(InitializationVectors)：當(dāng)使用CBC模式的分組密碼時(shí)，每個(gè)密鑰都需要一個(gè)初始化向量。該域首次由SSL握手協(xié)議初始化。其后每條記錄的最后密文塊保留作為下一條記錄的IV。

(6)服務(wù)器寫初始化向量(InitializationVectors)：客戶機(jī)寫參數(shù)用于服務(wù)器對(duì)接收到的記錄進(jìn)行處理，同樣的服務(wù)器寫參數(shù)也會(huì)被客戶機(jī)用來(lái)對(duì)接收到的記錄進(jìn)行處理。

一旦設(shè)置好安全參數(shù)并產(chǎn)生上述密鑰，此連接狀態(tài)將被實(shí)例化為當(dāng)前狀態(tài)。后續(xù)記錄層的處理都以此連接狀態(tài)所規(guī)定的安全元素進(jìn)行處理。每個(gè)連接狀態(tài)包含下列安全元素：

(1)壓縮狀態(tài)：壓縮算法的當(dāng)前狀態(tài)。

(2)密碼狀態(tài)：加密算法的當(dāng)前狀態(tài)。

(3)

MAC密鑰：本連接的MAC密鑰。

(4)序列號(hào)(SequenceNumbers)：每個(gè)連接狀態(tài)都包含一個(gè)序列號(hào)，雙方都各自維護(hù)自己的序列號(hào)用于讀和寫狀態(tài)。每當(dāng)某一方發(fā)送或者接收一條改變密碼規(guī)范消息，都將把序列號(hào)設(shè)成零。序列號(hào)的類型為uint64，其值不能超過(guò)264-1。

因此，SSL/TLS連接狀態(tài)規(guī)定了壓縮算法、加密算法和MAC算法以及上述算法的參數(shù)。邏輯上，總共有四種連接狀態(tài)：當(dāng)前的讀、寫狀態(tài)和未決的讀、寫狀態(tài)。所有的記錄都是在當(dāng)前的讀寫狀態(tài)下處理。未決狀態(tài)的安全參數(shù)可以通過(guò)SSL/TLS握手協(xié)議進(jìn)行設(shè)置。初始的當(dāng)前狀態(tài)必須是無(wú)加密、無(wú)壓縮或者無(wú)MAC。沒有用安全參數(shù)進(jìn)行初始化的狀態(tài)不能成為當(dāng)前狀態(tài)。

SSL/TLS握手協(xié)議負(fù)責(zé)協(xié)商一個(gè)會(huì)話，其包含下列元素：

(1)會(huì)話標(biāo)識(shí)符(SessionIdentifier)：由服務(wù)器選擇的一個(gè)任意字節(jié)序列，用于識(shí)別一個(gè)激活的或可恢復(fù)的會(huì)話狀態(tài)。

(2)對(duì)等實(shí)體證書(PeerCertificate)：對(duì)等實(shí)體的X509.v3證書。該狀態(tài)可為空。

(3)壓縮方法(CompressionMethod)：在加密之前用于壓縮數(shù)據(jù)的算法。

(4)密碼規(guī)范(CipherSpec)：規(guī)定了用于產(chǎn)生密鑰材料的偽隨機(jī)函數(shù)(PRF)，分組加密算法(如null，AES等)以及MAC算法(如HMAC-SHA1)。同樣還定義了密碼屬性，例如哈希長(zhǎng)度。

(5)主密鑰(MasterSecret)：客戶機(jī)和服務(wù)器共享的48字節(jié)秘密。

(6)是否可恢復(fù)(IsResumable)：確定該會(huì)話是否可用于發(fā)起新連接的一個(gè)標(biāo)志。

上述各項(xiàng)用于創(chuàng)建SSL/TLS記錄層保護(hù)應(yīng)用數(shù)據(jù)所需要使用的安全參數(shù)。一個(gè)會(huì)話可以用來(lái)實(shí)例化多個(gè)連接。這是通過(guò)SSL/TLS握手協(xié)議的可恢復(fù)功能來(lái)實(shí)現(xiàn)的。

7.2SSL/TLS記錄協(xié)議

SSL/TLS協(xié)議的底層是記錄協(xié)議層。SSL/TLS記錄協(xié)議在客戶機(jī)和服務(wù)器之間傳輸應(yīng)用數(shù)據(jù)和SSL/TLS控制數(shù)據(jù)。記錄層數(shù)據(jù)可以被隨意壓縮、加密，然后與消息驗(yàn)證碼壓縮在一起。每個(gè)記錄層數(shù)據(jù)包都有一個(gè)Content-Type段用以記錄更上層用的協(xié)議。

圖7-3描述了SSL/TLS記錄協(xié)議的整個(gè)操作過(guò)程。圖7-3記錄協(xié)議操作流程

第一步是分段。每一個(gè)高層消息都要分段，使其長(zhǎng)度不超過(guò)214字節(jié)。需要注意的是，不同類型的內(nèi)容有可能被交織在一起。第二步是所有的記錄采用當(dāng)前會(huì)話狀態(tài)中的壓縮算法進(jìn)行壓縮。SSL3.0版本沒有指定壓縮算法，TLS1.2的壓縮算法由RFC3749規(guī)定。但是壓縮必須是無(wú)損的，而且不會(huì)增加1024字節(jié)以上長(zhǎng)度的內(nèi)容。一般我們總希望壓縮是縮短了數(shù)據(jù)而不是擴(kuò)大了數(shù)據(jù)。但是對(duì)于非常短的數(shù)據(jù)塊，由于格式原因，有可能壓縮算法的輸出長(zhǎng)于輸入。

下一步是給壓縮后的數(shù)據(jù)計(jì)算消息驗(yàn)證碼。這一步在SSL和TLS協(xié)議中差異比較大，下面分別進(jìn)行討論。

7.2.1SSL3.0的MAC計(jì)算

MAC使用下面公式進(jìn)行計(jì)算：

hash(MAC_write_secret+pad_2+

hash(MAC_write_secret+pad_1+seq_num+

SSLCompressed.type+SSLCompressed.length+

SSLCompressed.fragment));

其中，“+”代表連接操作；MAC_write_secret為客戶服務(wù)器共享的秘密；pad_1為字符0x36重復(fù)48次(MD5)或40次(SHA)；pad_2為字符0x5c重復(fù)48次(MD5)或40次(SHA)；seq_num為該報(bào)文的消息序列號(hào)；hash為哈希算法；SSLCompressed.type為處理分段的高層協(xié)議類型；SSLCompressed.length為壓縮分段長(zhǎng)度；SSLCompressed.fragment為壓縮分段(沒有壓縮時(shí)，就是明文分段)。

注意：MAC運(yùn)算要先于加密運(yùn)算進(jìn)行。

7.2.2TLS1.2的MAC計(jì)算

TLS記錄層使用RFC2104中定義的鍵值消息認(rèn)證碼(HMAC)算法來(lái)保護(hù)消息的完整性，其計(jì)算式如下：

MAC(MAC_write_key,seq_num+

TLSCompressed.type+

TLSCompressed.version+

TLSCompressed.length+

TLSCompressed.fragment);

接著，使用對(duì)稱加密算法給添加了MAC的壓縮消息進(jìn)行加密，而且加密不能增加1024字節(jié)以上的內(nèi)容長(zhǎng)度。

實(shí)現(xiàn)SSL/TLS記錄協(xié)議的最后一步是添加報(bào)頭，它包含以下字段：

內(nèi)容類型(8位)：所封裝分段的高層協(xié)議類型。

主版本(8位)：使用SSL/TLS協(xié)議的主要版本號(hào)。對(duì)SSL和TLS,值都為3。

次版本(8位)：使用SSL/TLS協(xié)議的次要版本號(hào)。對(duì)SSLv3，值為0；對(duì)TLS1.0，值為1；對(duì)TLS1.1，值為2；對(duì)TLS1.2，值為3。

壓縮長(zhǎng)度(16位)：分段的字節(jié)長(zhǎng)度，不能超過(guò)214個(gè)字節(jié)。

圖7-4描述了SSL/TLS記錄報(bào)文格式。

內(nèi)容類型字段給出了記錄報(bào)文所攜帶的協(xié)議信息，目前支持四種高層協(xié)議，分別是握手協(xié)議(22)、告警協(xié)議(21)、改變密碼規(guī)范協(xié)議(20)和應(yīng)用數(shù)據(jù)協(xié)議(23)。

圖7-4記錄報(bào)文格式

7.3改變密碼規(guī)范協(xié)議

改變密碼規(guī)范協(xié)議是使用SSL/TLS記錄協(xié)議的三個(gè)特定協(xié)議之一(由記錄頭的內(nèi)容類型字段取值為20確定)，也是最為簡(jiǎn)單的協(xié)議，如圖7-5所示。協(xié)議由單個(gè)字節(jié)消息組成。改變密碼規(guī)范協(xié)議用于從一種加密算法轉(zhuǎn)變?yōu)榱硗庖环N加密算法。雖然加密規(guī)范通常是在SSL/TLS握手協(xié)議結(jié)束時(shí)才被改變，但實(shí)際上，它可以由客戶機(jī)或者服務(wù)器在任何時(shí)候通知接收方實(shí)體，后續(xù)的記錄將采用最新協(xié)商的密碼規(guī)范和密鑰進(jìn)行保護(hù)。圖7-5改變密碼規(guī)范協(xié)議

收到此報(bào)文的接收方將指令記錄層從讀未決狀態(tài)拷貝信息到讀當(dāng)前狀態(tài)。同時(shí)發(fā)送方在發(fā)送此報(bào)文以后，將馬上指令記錄層由寫未決狀態(tài)進(jìn)入寫激活狀態(tài)。

7.4告警協(xié)議

告警是能夠通過(guò)SSL/TLS記錄協(xié)議進(jìn)行傳輸?shù)奶囟愋拖ⅲ糜趥鬏斚⒌膰?yán)重性以及告警消息的說(shuō)明。告警由兩個(gè)部分組成：告警級(jí)別和告警的含義說(shuō)明，具體組成如圖7-6所示。它們都用8比特進(jìn)行編碼。告警消息也被壓縮和加密。圖7-6告警協(xié)議

告警有兩個(gè)級(jí)別，如表7-1所示。

7.5握手協(xié)議

SSL/TLS中最復(fù)雜的部分就是握手協(xié)議，它工作在記錄層協(xié)議之上，用于建立會(huì)話狀態(tài)的密碼參數(shù)，協(xié)商會(huì)話的安全屬性。每當(dāng)SSL/TLS客戶和服務(wù)器首次進(jìn)行安全通信，都需要相互之間協(xié)商協(xié)議版本、選擇密碼算法、認(rèn)證雙方身份(可選)、使用公鑰加密技術(shù)來(lái)產(chǎn)生共享秘密。

SSL/TLS握手協(xié)議通常包含下列步驟：

(1)交換hello報(bào)文來(lái)達(dá)成一致的算法、交換隨機(jī)數(shù)和檢查是否恢復(fù)會(huì)話。

(2)交換必要的密碼參數(shù)來(lái)達(dá)成一致的次密鑰(premastersecret)。

(3)交換證書和密碼信息，允許客戶和服務(wù)器互相進(jìn)行身份認(rèn)證。

(4)由次密鑰和交換的隨機(jī)值產(chǎn)生主密鑰(mastersecret)。

(5)為記錄層提供安全參數(shù)。

(6)允許客戶和服務(wù)器各自驗(yàn)證對(duì)方已經(jīng)計(jì)算得到相同的安全參數(shù)且整個(gè)握手過(guò)程沒有受到攻擊。

上述步驟的實(shí)現(xiàn)是由一系列客戶機(jī)和服務(wù)器的消息交換來(lái)實(shí)現(xiàn)。交換的消息格式如圖7-7所示。所有的握手報(bào)文都以4字節(jié)報(bào)文頭開始，其中的第一個(gè)字節(jié)是握手報(bào)文類型，后三個(gè)字節(jié)是報(bào)文長(zhǎng)度(不包括頭)。

圖7-7握手協(xié)議

SSL/TLS握手協(xié)議、SSL/TLS改變密碼規(guī)范協(xié)議、SSL/TLS告警協(xié)議以及應(yīng)用層協(xié)議的數(shù)據(jù)都被封裝進(jìn)入SSL記錄協(xié)議。封裝后的協(xié)議作為數(shù)據(jù)被發(fā)送到更低層協(xié)議進(jìn)行處理。

SSL/TLS協(xié)議和TCP/IP協(xié)議之間的封裝關(guān)系如圖7-8所示。

圖7-8握手協(xié)議封裝

整個(gè)SSL/TLS握手過(guò)程根據(jù)客戶服務(wù)器的配置不同而不同，相應(yīng)的也就有不同的消息交換。通常我們可以把SSL/TLS握手過(guò)程分成以下四類：

(1)常規(guī)SSL/TLS握手過(guò)程。

(2)包含客戶端認(rèn)證的SSL/TLS握手過(guò)程。

(3)恢復(fù)以前的SSL/TLS會(huì)話的握手過(guò)程。

(4)

SSL2.0握手過(guò)程。

7.5.1常規(guī)握手過(guò)程

常見的SSL/TLS握手過(guò)程是使用RSA密鑰交換，而且只對(duì)服務(wù)器的身份進(jìn)行認(rèn)證。為了減少交換的分組數(shù)量，多個(gè)SSL/TLS記錄有可能被封裝到單個(gè)分組進(jìn)行傳輸。一次新SSL/TLS握手的報(bào)文交換過(guò)程如下。

(1)客戶發(fā)送一個(gè)ClientHello報(bào)文給服務(wù)器，包含的內(nèi)容如下：

①協(xié)議版本。客戶機(jī)支持的最高版本號(hào)。

②隨機(jī)數(shù)。由4字節(jié)的時(shí)間戳和28字節(jié)的隨機(jī)數(shù)組成。

③會(huì)話ID?？勺冮L(zhǎng)度的會(huì)話標(biāo)識(shí)。如果客戶要開始一個(gè)新的會(huì)話，會(huì)話ID的值為0。

④密碼組。客戶機(jī)所支持的加密算法組合，按客戶的優(yōu)先權(quán)降序排列。每個(gè)密碼組定義了一種密鑰交換算法、一種分組密碼算法(包括密鑰長(zhǎng)度)、一種MAC算法和一個(gè)PRF函數(shù)。

⑤壓縮方法。客戶機(jī)支持的壓縮方法列表，按客戶的優(yōu)先權(quán)降序排列。

(2)服務(wù)器以ClientHello報(bào)文進(jìn)行應(yīng)答，應(yīng)答內(nèi)容包含：

①

SSL/TLS會(huì)話將要使用的版本號(hào)。

②?SSL/TLS會(huì)話將要使用的密碼組。

③

SSL/TLS會(huì)話將要使用的數(shù)據(jù)壓縮方法。

④

SSL/TLS會(huì)話將要使用的會(huì)話ID。

⑤服務(wù)器產(chǎn)生的隨機(jī)數(shù)。

上述的ClientHello和ClientHello兩個(gè)報(bào)文交換完以后，客戶和服務(wù)器之間已經(jīng)建立最基本的安全能力，達(dá)成了以下的安全屬性：協(xié)議版本號(hào)、會(huì)話ID、密碼組和壓縮算法。此外還生成了兩個(gè)隨機(jī)數(shù)并進(jìn)行交換，它們將用于后續(xù)的密鑰產(chǎn)生。

(3)在hello報(bào)文之后，服務(wù)器將使用Certificate報(bào)文把自己的數(shù)字證書，甚至證書鏈發(fā)送給客戶端。

(4)在某些情況下，服務(wù)器提供的證書還不足以讓客戶來(lái)完成次密鑰的交換，此時(shí)服務(wù)器需要緊接著發(fā)送一個(gè)ServerKeyExchange報(bào)文給客戶。該報(bào)文通常包含額外的密鑰交換參數(shù)，如Diffie-Hellman密鑰交換所需的素?cái)?shù)和元根。

(5)服務(wù)器發(fā)送ServerHelloDone報(bào)文，告訴客戶服務(wù)器已經(jīng)完成該階段的握手。

(6)在接收到服務(wù)器完成消息之后，客戶需要驗(yàn)證服務(wù)器是否提供合法的數(shù)字證書，并檢查ServerHello報(bào)文的參數(shù)是否可以接受。然后客戶發(fā)送ClientKeyExchange報(bào)文給服務(wù)器。報(bào)文內(nèi)容是使用服務(wù)器公鑰加密的48字節(jié)長(zhǎng)的次密鑰。客戶和服務(wù)器將各自利用次密鑰和隨機(jī)數(shù)來(lái)生成對(duì)稱加密的主密鑰。

(7)客戶發(fā)送ChangeCipherSpec報(bào)文給服務(wù)器。注意，此報(bào)文并非握手協(xié)議的一部分，而是使用改變密碼規(guī)范協(xié)議發(fā)送的。該報(bào)文表明客戶發(fā)送的后續(xù)SSL/TLS記錄層數(shù)據(jù)將是加密的。5字節(jié)長(zhǎng)的記錄頭是不加密的。

(8)客戶發(fā)送完成消息Finished報(bào)文。報(bào)文內(nèi)容是客戶和服務(wù)器之間到目前為止所有握手報(bào)文的哈希值，從而完成對(duì)密鑰交換和認(rèn)證過(guò)程的有效驗(yàn)證。這主要是因?yàn)榍懊嬖诳蛻艉头?wù)器之間交換的報(bào)文都是明文，有可能遭受修改或者重放等攻擊。

(9)服務(wù)器發(fā)送自己的改變密碼規(guī)范ChangeCipher-Spec報(bào)文。

(10)服務(wù)器發(fā)送Finished報(bào)文。

創(chuàng)建新會(huì)話的整個(gè)握手過(guò)程圖如圖7-9所示。

圖7-9會(huì)話創(chuàng)建握手過(guò)程

7.5.2帶客戶端認(rèn)證的握手過(guò)程

如果服務(wù)器需要對(duì)客戶的身份進(jìn)行認(rèn)證，那么在常規(guī)握手過(guò)程的基礎(chǔ)上，將增加額外的三個(gè)報(bào)文交換，如圖7-10所示，分別是：

(1)在服務(wù)器發(fā)送ServerDone報(bào)文之前，服務(wù)器將給客戶發(fā)送CertificateRequest報(bào)文，以要求客戶提供其證書。這個(gè)報(bào)文包含了證書類型、服務(wù)器支持的簽名和哈希算法以及服務(wù)器可以信任和接受的證書頒發(fā)機(jī)構(gòu)(CA)的列表。

(2)客戶給服務(wù)器發(fā)送Certificate報(bào)文。

(3)客戶給服務(wù)器發(fā)送CertificateVerify報(bào)文。該報(bào)文包含使用客戶私鑰進(jìn)行簽名的握手報(bào)文的哈希值。此處的握手報(bào)文是指從客戶hello報(bào)文開始到此報(bào)文為止(不含本報(bào)文)的所有的報(bào)文信息，包括類型和長(zhǎng)度字段。服務(wù)器收到該報(bào)文后，計(jì)算其哈希值，然后使用客戶數(shù)字證書中的公鑰來(lái)驗(yàn)證簽名的有效性，從而驗(yàn)證客戶的身份。

圖7-10支持客戶認(rèn)證的握手過(guò)程

7.5.3恢復(fù)SSL/TLS會(huì)話

當(dāng)一個(gè)SSL/TLS會(huì)話是正常結(jié)束而且客戶和服務(wù)器都緩存了會(huì)話信息，就有可能在后續(xù)的什么時(shí)候恢復(fù)該SSL/TLS會(huì)話，而不用重新協(xié)商安全參數(shù)計(jì)算次密鑰。

要恢復(fù)SSL/TLS會(huì)話，客戶在發(fā)送ClientHello報(bào)文時(shí)，需要包含特定SSL/TLS會(huì)話的ID。如果服務(wù)器在其緩存中沒有找到這個(gè)會(huì)話ID，那么服務(wù)器將返回一個(gè)包含新會(huì)話ID的ServerHello報(bào)文給客戶，從而啟動(dòng)新的SSL/TLS會(huì)話創(chuàng)建進(jìn)程。

如果服務(wù)器的緩存中確實(shí)存在客戶所要求的會(huì)話ID，服務(wù)器將在ServerHello報(bào)文中重復(fù)該會(huì)話ID。然后客戶和服務(wù)器將利用緩存的參數(shù)信息和新產(chǎn)生的隨機(jī)數(shù)得到新的加密密鑰。

圖7-11給出了恢復(fù)SSL/TLS會(huì)話的報(bào)文交換過(guò)程。

圖7-11會(huì)話恢復(fù)握手過(guò)程

7.5.4SSL2.0握手過(guò)程

SSL2.0握手過(guò)程如圖7-12所示。

圖7-12SSL2.0握手過(guò)程

(1)客戶發(fā)送ClientHello報(bào)文。其中包含客戶支持的密碼組、產(chǎn)生的隨機(jī)數(shù)以及會(huì)話ID。

(2)服務(wù)器發(fā)送ServerHello報(bào)文。其中包括服務(wù)器支持的密碼組子集，服務(wù)器的數(shù)字證書和一個(gè)連接ID。連接ID的功能等同于SSL3.0握手過(guò)程中服務(wù)器產(chǎn)生的隨機(jī)數(shù)。不過(guò)在SSL3.0握手過(guò)程中是服務(wù)器選擇密碼組然后告訴客戶端，而在SSL2.0中是由客戶選擇所使用的密碼組。

(3)客戶發(fā)送ClientMasterKey報(bào)文。其中包含了要使用的密碼組、用服務(wù)器公鑰加密的主密鑰。

(4)客戶發(fā)送ClientFinished報(bào)文，其中包含了服務(wù)器提供的連接ID。服務(wù)器由此來(lái)驗(yàn)證客戶是否知道加密密鑰。這是第一個(gè)加密的報(bào)文。

(5)服務(wù)器發(fā)送ServerVerify報(bào)文。這個(gè)報(bào)文的內(nèi)容是ClientHello報(bào)文中挑戰(zhàn)數(shù)據(jù)(隨機(jī)數(shù))的加密密文。由此，客戶可以驗(yàn)證服務(wù)器的身份。

(6)服務(wù)器發(fā)送ServerFinished報(bào)文，其中包含了會(huì)話ID。客戶可以使用該會(huì)話ID實(shí)現(xiàn)會(huì)話的后續(xù)恢復(fù)。

對(duì)一個(gè)SSL2.0會(huì)話的恢復(fù)就是簡(jiǎn)單的忽略上述的第三個(gè)步驟。如果服務(wù)器能夠支持某個(gè)會(huì)話ID的恢復(fù)，服務(wù)器將在ServerHello報(bào)文中設(shè)置特定標(biāo)志。

SSL2.0也支持對(duì)客戶端的認(rèn)證。服務(wù)器將發(fā)送一個(gè)RequestCertificate報(bào)文給客戶，然后客戶以ClientCertificate報(bào)文進(jìn)行應(yīng)答。

通過(guò)上述四種握手過(guò)程的討論，可以把整個(gè)握手過(guò)程分成四個(gè)階段，如圖7-13所示，每個(gè)階段的功能、獲得的信息客戶端和服務(wù)器端的握手協(xié)議由以下幾部分組成：

(1)協(xié)商數(shù)據(jù)傳送期間使用的密碼組、會(huì)話ID、壓縮方法和隨機(jī)數(shù)，建立安全能力。

(2)服務(wù)器發(fā)送自己的證書，交換密鑰、請(qǐng)求客戶證書、完成hello消息。

(3)認(rèn)證客戶身份，發(fā)送交換密鑰，發(fā)送證書驗(yàn)證消息。

(4)改變密碼組，結(jié)束握手協(xié)議。

圖7-13握手過(guò)程全景圖

7.6密鑰計(jì)算

為了保護(hù)連接數(shù)據(jù)，SSL/TLS記錄層需要知道加解密算法、認(rèn)證算法、MAC算法、主密鑰和客戶服務(wù)器的隨機(jī)數(shù)。認(rèn)證、加密和MAC算法是通過(guò)ServerHello報(bào)文來(lái)完成協(xié)商的。同樣的壓縮算法和隨機(jī)數(shù)也可以通過(guò)hello報(bào)文獲得，剩下的未知參數(shù)就是主密鑰。

7.6.1計(jì)算主密鑰

不管使用什么密鑰交換方法，從次密鑰來(lái)計(jì)算主密鑰的算法都是相同的。一旦計(jì)算出主密鑰，就應(yīng)當(dāng)從內(nèi)存中刪除次密鑰。

1．TLS計(jì)算方法

master_secret=PRF(pre_master_secret,“mastersecret”,

ClientHello.random+ServerHello.random)

[0..47];

2．SSL計(jì)算方法

master_secret=

MD5(pre_master_secret+SHA(‘A’+pre_master_secret+

ClientHello.random+ServerHello.random))+

MD5(pre_master_secret+SHA(‘BB’+pre_master_secret+

ClientHello.random+ServerHello.random))+

MD5(pre_master_secret+SHA(‘CCC’+pre_master_secret+

ClientHello.random+ServerHello.random));

主密鑰長(zhǎng)度固定，為48字節(jié)，而次密鑰的長(zhǎng)度將根據(jù)密鑰交換方法的不同而不同。

使用RSA作為認(rèn)證和密鑰交換方法時(shí)，48字節(jié)長(zhǎng)的次密鑰是由客戶產(chǎn)生的，并用服務(wù)器的公鑰加密后發(fā)送給服務(wù)器。服務(wù)器使用自己的私鑰解密出次密鑰。然后客戶和服務(wù)器各自把次密鑰轉(zhuǎn)換為主密鑰。

如果使用Diffie-Hellman密鑰交換方法，則使用協(xié)商得到的公鑰Z作為次密鑰，然后轉(zhuǎn)換成主密鑰。公鑰Z的所有前導(dǎo)0字節(jié)都會(huì)被忽略。

7.6.2偽隨機(jī)函數(shù)(PRF)

有了主密鑰，TLS記錄層還需要某種算法對(duì)從握手協(xié)議獲取的安全參數(shù)計(jì)算出來(lái)的主密鑰進(jìn)行擴(kuò)展，從而產(chǎn)生當(dāng)前連接狀態(tài)所需要的其它密鑰。

在TLS協(xié)議中，密鑰的擴(kuò)展是通過(guò)偽隨機(jī)函數(shù)(PRF)函數(shù)來(lái)實(shí)現(xiàn)的，它以一個(gè)密鑰、種子和一個(gè)可識(shí)別標(biāo)簽作為輸入，輸出任意長(zhǎng)度的數(shù)據(jù)。

TLS定義的PRF是基于HMAC。它對(duì)所有的密碼組都使用SHA-256哈希函數(shù)。TLS首先定義了一個(gè)數(shù)據(jù)擴(kuò)展函數(shù)，P_hash(secret,data)，該函數(shù)使用單個(gè)哈希函數(shù)來(lái)擴(kuò)展一個(gè)密鑰和種子，以得到任意長(zhǎng)度的輸出。

P_hash(secret,seed)=HMAC_hash(secret,A(1)+seed)