二、SSL握手過(guò)程：
1. 客戶(hù)端將它所支持的算法列表和一個(gè)用作產(chǎn)生密鑰的隨機數發(fā)送給服務(wù)器；
2. 服務(wù)器從算法列表中選擇一種加密算法，并將它和一份包含服務(wù)器公用密鑰的證書(shū)發(fā)送給客戶(hù)端；該證書(shū)還包含了用于認證目的的服務(wù)器標識，服務(wù)器同時(shí)還提供了一個(gè)用作產(chǎn)生密鑰的隨機數；
3. 客戶(hù)端對服務(wù)器的證書(shū)進(jìn)行驗證(有關(guān)驗證證書(shū)，可以參考數字簽名)，并抽取服務(wù)器的公用密鑰；然后，再產(chǎn)生一個(gè)稱(chēng)作pre_master_secret的隨機密碼串，并使用服務(wù)器的公用密鑰對其進(jìn)行加密(參考非對稱(chēng)加/解密)，并將加密后的信息發(fā)送給服務(wù)器；
4. 客戶(hù)端與服務(wù)器端根據pre_master_secret以及客戶(hù)端與服務(wù)器的隨機數值獨立計算出加密和MAC密鑰(參考DH密鑰交換算法)。
5. 客戶(hù)端將所有握手消息的MAC值發(fā)送給服務(wù)器；
6. 服務(wù)器將所有握手消息的MAC值發(fā)送給客戶(hù)端。
第5與第6步用以防止握手本身遭受篡改。設想一個(gè)攻擊者想要控制客戶(hù)端與服務(wù)器所使用的算法?？蛻?hù)端提供多種算法的情況相當常見(jiàn)，某些強度弱而某些強度 強，以便能夠與僅支持弱強度算法的服務(wù)器進(jìn)行通信。攻擊者可以刪除客戶(hù)端在第1步所提供的所有高強度算法，于是就迫使服務(wù)器選擇一種弱強度的算法。第5步 與第6步的MAC交換就能阻止這種攻擊，因為客戶(hù)端的MAC是根據原始消息計算得出的，而服務(wù)器的MAC是根據攻擊者修改過(guò)的消息計算得出的，這樣經(jīng)過(guò)檢 查就會(huì )發(fā)現不匹配。由于客戶(hù)端與服務(wù)器所提供的隨機數為密鑰產(chǎn)生過(guò)程的輸入，所以握手不會(huì )受到重放攻擊的影響。這些消息是首個(gè)在新的加密算法與密鑰下加密 的消息。
剛才所描述的每一步都需要通過(guò)一條或多條握手消息來(lái)實(shí)現。在此先簡(jiǎn)要地描述哪些消息與哪幾步相對應，然后詳細描述每條消息的內容。下圖描述了各條消息：
第1步對應一條單一的握手消息，ClientHello.
第2步對應一系列SSL握手消息，服務(wù)器發(fā)送的第一條消息為ServerHello，其中包含了它所選擇的算法，接著(zhù)再在Certificate消息中發(fā) 送其證書(shū)。最后，服務(wù)器發(fā)送ServerHelloDone消息以表示這一握手階段的完成。需要ServerHelloDone的原因是一些更為復雜的握 手變種還要在Certifacate之后發(fā)送其他一些消息。當客戶(hù)端接收到ServerHelloDone消息時(shí)，它就知道不會(huì )再有其他類(lèi)似的消息過(guò)來(lái) 了，于是就可以繼續它這一方的握手。
第3步對應ClientKeyExchange消息。
第5與第6步對應Finished消息。該消息是第一條使用剛剛磋商過(guò)的算法加以保護的消息。為了防止握手過(guò)程遭到篡改，該消息的內容是前一階段所有握手 消息的MAC值。然而，由于Finished消息是以磋商好的算法加以保護的，所以也要與新磋商的MAC密鑰—起計算消息本身的MAc值。
注意，上圖中省略了兩條ChangeCipherSpec消息。
三、SSL記錄協(xié)議：
在SSL中，實(shí)際的數據傳輸是使用SSL記錄協(xié)議來(lái)實(shí)現的。SSL記錄協(xié)議是通過(guò)將數據流分割成一系列的片段并加以傳輸來(lái)工作的，其中對每個(gè)片段單獨進(jìn)行 保護和傳輸。在接收方，對每條記錄單獨進(jìn)行解密和驗證。這種方案使得數據一經(jīng)準備好就可以從連接的一端傳送到另一端，并在接收到的即刻加以處理。
在傳輸片段之前，必須防止其遭到攻擊?？梢酝ㄟ^(guò)計算數據的MAC來(lái)提供完整性保護。MAC與片段一起進(jìn)行傳輸，并由接收實(shí)現加以驗證。將MAC附加到片段 的尾部，并對數據與MAC整合在一起的內容進(jìn)行加密，以形成經(jīng)過(guò)加密的負載(Payload)。最后給負載裝上頭信息。頭信息與經(jīng)過(guò)加密的負載的連結稱(chēng)作 記錄(record)，記錄就是實(shí)際傳輸的內容。下圖描述了傳輸過(guò)程：
3.1 記錄頭消息：
記錄頭信息的工作就是為接收實(shí)現(receiving implementation)提供對記錄進(jìn)行解釋所必需的信息。在實(shí)際應用中，它是指三種信息：內容類(lèi)型、長(cháng)度和SSL版本。長(cháng)度字段可以讓接收方知道 他要從線(xiàn)路上這取多少字節才能對消息進(jìn)行處理，版本號只是一項確保每一方使用所磋商的版本的冗余性檢查。內容類(lèi)型字段表示消息類(lèi)型。
3.2 SSL記錄類(lèi)型：
SSL支持四種內容類(lèi)型：application_data、alert、handshake和change_cipher_spec。
使用SSL的軟件發(fā)送和接收的所有數據都是以application_data類(lèi)型來(lái)發(fā)送的，其他三種內容類(lèi)型用于對通信進(jìn)行管理，如完成握手和報告錯誤等。
內容類(lèi)型alert主要用于報告各種類(lèi)型的錯誤。大多數alert(警示)用于報告握手中出現的問(wèn)題，但也有一些指示在對記錄試圖進(jìn)行解密或認證時(shí)發(fā)生的錯誤，alert消息的其他用途是指示連接將要關(guān)閉。
內容類(lèi)型handshake用于承載握手消息。 即便是最初形成連接的握手消息也是通過(guò)記錄層以handshake類(lèi)型的記錄來(lái)承載的。由于加密密鑰還未確立，這些初始的消息并未經(jīng)過(guò)加密或認證，但是其 他處理過(guò)程是一樣的。有可能在現有的連接上初始化一次新的握手，在這種情況下，新的握手記錄就像其他的數據一樣，要經(jīng)過(guò)加密和認證。
change_cipher_spec消息表示記錄加密及認證的改變。一旦握手商定了一組新的密鑰，就發(fā)送change_cipher_spec來(lái)指示此刻將啟用新的密鑰。
四、各種消息協(xié)同工作：
正如我們所看到的，SSL是一種分層協(xié)議，它以一個(gè)記錄層以及記錄層上承裁的個(gè)同消息類(lèi)型組成。而該記錄層又會(huì )由某種可靠的傳輸協(xié)議如TCP來(lái)承載。下圖描述了該協(xié)以的結構：
五、一次SSL連接的完整過(guò)程：
聯(lián)系客服
