SSL握手有三個目的： 1. 客戶端與服務(wù)器需要就一組用于保護(hù)數(shù)據(jù)的算法達(dá)成一致； 2. 它們需要確立一組由那些算法所使用的加密密鑰； 3. 握手還可以選擇對客戶端進(jìn)行認(rèn)證。

一、SSL握手有三個目的：
1. 客戶端與服務(wù)器需要就一組用于保護(hù)數(shù)據(jù)的算法達(dá)成一致；
2. 它們需要確立一組由那些算法所使用的加密密鑰；
3. 握手還可以選擇對客戶端進(jìn)行認(rèn)證。

二、SSL握手過程：
1. 客戶端將它所支持的算法列表和一個用作產(chǎn)生密鑰的隨機數(shù)發(fā)送給服務(wù)器；
2. 服務(wù)器從算法列表中選擇一種加密算法，并將它和一份包含服務(wù)器公用密鑰的證書發(fā)送給客戶端；該證書還包含了用于認(rèn)證目的的服務(wù)器標(biāo)識，服務(wù)器同時還提供了一個用作產(chǎn)生密鑰的隨機數(shù)；
3. 客戶端對服務(wù)器的證書進(jìn)行驗證(有關(guān)驗證證書，可以參考數(shù)字簽名)，并抽取服務(wù)器的公用密鑰；然后，再產(chǎn)生一個稱作pre_master_secret的隨機密碼串，并使用服務(wù)器的公用密鑰對其進(jìn)行加密(參考非對稱加/解密)，并將加密后的信息發(fā)送給服務(wù)器；
4. 客戶端與服務(wù)器端根據(jù)pre_master_secret以及客戶端與服務(wù)器的隨機數(shù)值獨立計算出加密和MAC密鑰(參考DH密鑰交換算法)。
5. 客戶端將所有握手消息的MAC值發(fā)送給服務(wù)器；
6. 服務(wù)器將所有握手消息的MAC值發(fā)送給客戶端。

    第5與第6步用以防止握手本身遭受篡改。設(shè)想一個攻擊者想要控制客戶端與服務(wù)器所使用的算法。客戶端提供多種算法的情況相當(dāng)常見，某些強度弱而某些強度強，以便能夠與僅支持弱強度算法的服務(wù)器進(jìn)行通信。攻擊者可以刪除客戶端在第1步所提供的所有高強度算法，于是就迫使服務(wù)器選擇一種弱強度的算法。第5步與第6步的MAC交換就能阻止這種攻擊，因為客戶端的MAC是根據(jù)原始消息計算得出的，而服務(wù)器的MAC是根據(jù)攻擊者修改過的消息計算得出的，這樣經(jīng)過檢查就會發(fā)現(xiàn)不匹配。由于客戶端與服務(wù)器所提供的隨機數(shù)為密鑰產(chǎn)生過程的輸入，所以握手不會受到重放攻擊的影響。這些消息是首個在新的加密算法與密鑰下加密的消息。

    剛才所描述的每一步都需要通過一條或多條握手消息來實現(xiàn)。在此先簡要地描述哪些消息與哪幾步相對應(yīng)，然后詳細(xì)描述每條消息的內(nèi)容。下圖描述了各條消息：

    第1步對應(yīng)一條單一的握手消息，ClientHello.
    第2步對應(yīng)一系列SSL握手消息，服務(wù)器發(fā)送的第一條消息為ServerHello，其中包含了它所選擇的算法，接著再在Certificate消息中發(fā)送其證書。最后，服務(wù)器發(fā)送ServerHelloDone消息以表示這一握手階段的完成。需要ServerHelloDone的原因是一些更為復(fù)雜的握手變種還要在Certifacate之后發(fā)送其他一些消息。當(dāng)客戶端接收到ServerHelloDone消息時，它就知道不會再有其他類似的消息過來了，于是就可以繼續(xù)它這一方的握手。
    第3步對應(yīng)ClientKeyExchange消息。
    第5與第6步對應(yīng)Finished消息。該消息是第一條使用剛剛磋商過的算法加以保護(hù)的消息。為了防止握手過程遭到篡改，該消息的內(nèi)容是前一階段所有握手消息的MAC值。然而，由于Finished消息是以磋商好的算法加以保護(hù)的，所以也要與新磋商的MAC密鑰—起計算消息本身的MAc值。
    注意，上圖中省略了兩條ChangeCipherSpec消息。

三、SSL記錄協(xié)議：
    在SSL中，實際的數(shù)據(jù)傳輸是使用SSL記錄協(xié)議來實現(xiàn)的。SSL記錄協(xié)議是通過將數(shù)據(jù)流分割成一系列的片段并加以傳輸來工作的，其中對每個片段單獨進(jìn)行保護(hù)和傳輸。在接收方，對每條記錄單獨進(jìn)行解密和驗證。這種方案使得數(shù)據(jù)一經(jīng)準(zhǔn)備好就可以從連接的一端傳送到另一端，并在接收到的即刻加以處理。
    在傳輸片段之前，必須防止其遭到攻擊。可以通過計算數(shù)據(jù)的MAC來提供完整性保護(hù)。MAC與片段一起進(jìn)行傳輸，并由接收實現(xiàn)加以驗證。將MAC附加到片段的尾部，并對數(shù)據(jù)與MAC整合在一起的內(nèi)容進(jìn)行加密，以形成經(jīng)過加密的負(fù)載(Payload)。最后給負(fù)載裝上頭信息。頭信息與經(jīng)過加密的負(fù)載的連結(jié)稱作記錄(record)，記錄就是實際傳輸?shù)膬?nèi)容。下圖描述了傳輸過程：

3.1 記錄頭消息：
    記錄頭信息的工作就是為接收實現(xiàn)(receiving implementation)提供對記錄進(jìn)行解釋所必需的信息。在實際應(yīng)用中，它是指三種信息：內(nèi)容類型、長度和SSL版本。長度字段可以讓接收方知道他要從線路上這取多少字節(jié)才能對消息進(jìn)行處理，版本號只是一項確保每一方使用所磋商的版本的冗余性檢查。內(nèi)容類型字段表示消息類型。

3.2 SSL記錄類型：
    SSL支持四種內(nèi)容類型：application_data、alert、handshake和change_cipher_spec。
使用SSL的軟件發(fā)送和接收的所有數(shù)據(jù)都是以application_data類型來發(fā)送的，其他三種內(nèi)容類型用于對通信進(jìn)行管理，如完成握手和報告錯誤等。
    內(nèi)容類型alert主要用于報告各種類型的錯誤。大多數(shù)alert(警示)用于報告握手中出現(xiàn)的問題，但也有一些指示在對記錄試圖進(jìn)行解密或認(rèn)證時發(fā)生的錯誤，alert消息的其他用途是指示連接將要關(guān)閉。
    內(nèi)容類型handshake用于承載握手消息。即便是最初形成連接的握手消息也是通過記錄層以handshake類型的記錄來承載的。由于加密密鑰還未確立，這些初始的消息并未經(jīng)過加密或認(rèn)證，但是其他處理過程是一樣的。有可能在現(xiàn)有的連接上初始化一次新的握手，在這種情況下，新的握手記錄就像其他的數(shù)據(jù)一樣，要經(jīng)過加密和認(rèn)證。
    change_cipher_spec消息表示記錄加密及認(rèn)證的改變。一旦握手商定了一組新的密鑰，就發(fā)送change_cipher_spec來指示此刻將啟用新的密鑰。

四、各種消息協(xié)同工作：
    正如我們所看到的，SSL是一種分層協(xié)議，它以一個記錄層以及記錄層上承裁的個同消息類型組成。而該記錄層又會由某種可靠的傳輸協(xié)議如TCP來承載。下圖描述了該協(xié)以的結(jié)構(gòu)：

五、一次SSL連接的完整過程：



摘錄自《SSL與TLS》