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