SSL協議的握手過程

SSL握手的目的

第一，客戶端與服務器須要就一組用於保護數據的算法達成一致。

第二，它們須要確立一組由那些算法所使用的加密密鑰。

第三，握手還能夠選擇對客戶端進行認證。

SSL 握手概述

 

SSL 握手概述

（1）客戶端將它所支持的算法列表連同一個密鑰產生過程用做輸入的隨機數發送給服務器。

（2）服務器根據從列表的內容中選擇一種加密算法，並將其連同一份包含服務器公用密鑰的證書發回給客戶端。該證書還包含了用於認證目的的服務器標識，服務器同時還提供了一個做爲密鑰產生過程部分輸入的隨機數。

（3）客戶端對服務器的證書進行驗證，並抽取服務器的公用密鑰。而後，再產生一個稱作pre_master_secret 的隨機密碼串，並使用服務器的公用密鑰對其進行加密。最後，客戶端將加密後的信息發送給服務器。

（4）客戶端與服務器端根據pre_master_secret 以及客戶端與服務器的隨機數值獨立計算出加密和MAC 密鑰。

（5）客戶端將全部握手消息的MAC 值發送給服務器。

（6）服務器將全部握手消息的MAC 值發送給客戶端。

那麼，該過程達到了怎樣的效果呢？

還記得咱們的兩個目標是什麼嗎？

第一個目標，就一組算法達成一致。確立一組加密密鑰。第一和第二步實現了第一個目標。客戶端告訴服務器它所支持的算法，而服務器選擇其中的一種算法。當客戶端收到了服務器在第二步所發的消息時，它也會知道這種算法，因此雙方如今就都知道要使用什麼算法了。

第二個目標，確立一組加密密鑰是經過第二和第三步來實現的。在第2 步服務器向客戶端提供其證書，這樣就能夠容許客戶端給服務器傳送密碼。通過第3 步後，客戶端與服務器端就都知道了pre_master_secret。客戶端知道pre_master_secret 是由於這是它產生的，而服務器則是經過解密而獲得pre_master_secret 的。注意，第3步是握手過程當中的關鍵一步。全部要被保護的數據都依賴於pre_master_secret的安全。

原理很是簡單：客戶端使用服務器的公用密鑰（從證書中抽取的）來加密共享密鑰，而服務器使用其私用密鑰對共享密鑰進行解密。握手的剩餘步驟主要用於確保這種交換過程的安全進行。而後在第4步，客戶端與服務器分別使用相同的密鑰導出函數（key derivationfunction，KDF）來產生master_secret，最後再次經過KDF 使用master_secret來產生加密密鑰。

第 5 與第6 步用以防止握手自己遭受篡改。設想一個攻擊者想要控制客戶端與服務器所使用的算法。客戶端提供多種算法的狀況至關常見，某些強度弱而某些強度強，以便可以與僅支持弱強度算法的服務器進行通訊。攻擊者能夠刪除客戶端在第1步所提供的全部高強度算法，因而就迫使服務器選擇一種弱強度的算法。第5步與第6 步的MAC交換就能阻止這種攻擊，由於客戶端的MAC 是根據原始消息計算得出的，而服務器的MAC是根據攻擊者修改過的消息計算得出的，這樣通過檢查就會發現不匹配。因爲客戶端與服務器所提供的隨機數爲密鑰產生過程的輸入，因此握手不會受到重放攻擊的影響。這些消息是首個在新的加密算法與密鑰下加密的消息。

所以，在此過程結束時，客戶端與服務器已就使用的加密算法達成一致，並擁有了一組與那些算法一塊兒使用的密鑰。更重要的是，它們能夠確信攻擊者沒有干擾握手過程，因此磋商過程反映了雙方的真實意圖。

 

握手消息

 

SSL 握手消息

第 1 步對應一條單一的握手消息，ClientHello。

第 2 步對應一系列SSL 握手消息，服務器發送的第一條件消息爲ServerHello，其中包含了它所選擇的算法，接着再在Certificate 消息中發送其證書。最後，服務器發送ServerHelloDone 消息以表示這一握手階段的完成。須要ServerHelloDone 的緣由是一些更爲複雜的握手變種還要在Certificate 以後發送其餘一些消息。當客戶端接收到ServerHelloDone消息時，它就知道不會再有其餘相似的消息過來了，因而就能夠繼續它這一方的握手。

第3步對應ClientKeyExchange 消息。

第5與第6 步對應Finished 消息。該消息是第一條使用剛剛磋商過的算法加以保護的消息。爲了防止握手過程遭到篡改，該消息的內容是前一階段全部握手消息的MAC值。然而，因爲Finished 消息是以磋商好的算法加以保護的，因此也要與新磋商的MAC密鑰一塊兒計算消息自己的MAC 值。

對於想深刻了解SSL協議的朋友，我向你們推薦《SSL與TLS.pdf》。

下載地址：

《SSL與TLS.pdf》

原創文章，轉載請註明： 轉載自成長的企鵝

本文連接地址： SSL協議的握手過程

關於我：成長的企鵝簡介