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》
