SSL協議握手工作流程詳解(雙向HTTPS流程)

標籤：針對   有用   簽名   網域名稱   一起   選擇   under   流程   相關   

參考學習文檔：http://www.cnblogs.com/jifeng/archive/2010/11/30/1891779.html

SSL協議的工作流程：

伺服器認證階段：

1）用戶端向伺服器發送一個開始資訊“Hello”以便開始一個新的會話串連；

2）伺服器根據客戶的資訊確定是否需要產生新的主要金鑰，如需要則伺服器在響應客戶的“Hello”資訊時將包含產生主要金鑰所需的資訊；

3）客戶根據收到的伺服器響應資訊，產生一個主要金鑰，並用伺服器的公開祕密金鑰加密後傳給伺服器；

4）伺服器恢複該主要金鑰，並返回給客戶一個用主要金鑰認證的資訊，以此讓客戶證明伺服器。

 使用者認證階段：

在此之前，伺服器已經通過了客戶認證，這一階段主要完成對客戶的認證。經認證的伺服器發送一個提問給客戶，客戶則返回（數字）簽名後的提問和其公開密鑰，從而向伺服器提供認證。

（SET協議：為網上信用卡支付提供了全球性的標準。）

 

SSL協議的握手過程：

SSL 協議既用到了公開金鑰加密技術(非對稱式加密)又用到了對稱式加密技術，SSL對傳輸內容的加密是採用的對稱式加密，然後對對稱式加密的密鑰使用公開金鑰進行非對稱式加密。這樣做的好處是，對稱式加密技術比公開金鑰加密技術的速度快，可用來加密較大的傳輸內容， 公開金鑰加密技術相對較慢，提供了更好的身份認證技術，可用來加密對稱式加密過程使用的密鑰。

      SSL 的握手協議非常有效讓客戶和伺服器之間完成相互之間的身份認證，其主要過程如下：
　　①用戶端的瀏覽器向伺服器傳送用戶端 SSL 協議的版本號碼，密碼編譯演算法的種類，產生的隨機數，以及其他伺服器和用戶端之間通訊所需要的各種資訊。

　　②伺服器向用戶端傳送 SSL 協議的版本號碼，密碼編譯演算法的種類，隨機數以及其他相關資訊，同時伺服器還將向用戶端傳送自己的認證。

　　③客戶利用伺服器傳過來的資訊驗證伺服器的合法性，伺服器的合法性包括：認證是否到期，發行伺服器憑證的 CA 是否可靠，發行者認證的公開金鑰能否正確解開伺服器憑證的“發行者的數位簽章”，伺服器憑證上的網域名稱是否和伺服器的實際網域名稱相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續進行第四步。

　　④使用者端隨機產生一個用於後面通訊的“對稱密碼”，然後用伺服器的公開金鑰（伺服器的公開金鑰從步驟②中的伺服器的認證中獲得）對其加密，然後將加密後的“預主密碼”傳給伺服器。 

　　⑤如果伺服器要求客戶的身份認證（在握手過程中為可選），使用者可以建立一個隨機數然後對其進行資料簽名，將這個含有簽名的隨機數和客戶自己的認證以及加密過的“預主密碼”一起傳給伺服器。

　　⑥如果伺服器要求客戶的身份認證，伺服器必須檢驗客戶認證和簽名隨機數的合法性，具體的合法性驗證過程包括：客戶的認證使用日期是否有效，為客戶提供認證的CA 是否可靠，發行CA 的公開金鑰能否正確解開客戶認證的發行 CA 的數位簽章，檢查客戶的認證是否在認證廢止列表（CRL）中。檢驗如果沒有通過，通訊立刻中斷；如果驗證通過，伺服器將用自己的私密金鑰解開加密的“預主密碼 ”，然後執行一系列步驟來產生主通訊密碼（用戶端也將通過同樣的方法產生相同的主通訊密碼）。

　　⑦伺服器和用戶端用相同的主密碼即“通話密碼”，一個對稱金鑰用於 SSL 協議的安全資料通訊的加解密通訊。同時在 SSL 通訊過程中還要完成資料通訊的完整性，防止資料通訊中的任何變化。

　　⑧用戶端向伺服器端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知伺服器用戶端的握手過程結束。

　　⑨伺服器向用戶端發出資訊，指明後面的資料通訊將使用的步驟⑦中的主密碼為對稱金鑰，同時通知用戶端伺服器端的握手過程結束。
　　⑩SSL 的握手部分結束，SSL 安全通道的資料通訊開始，客戶和伺服器開始使用相同的對稱金鑰進行資料通訊，同時進行通訊完整性的檢驗。

 

雙向認證 SSL 協議的具體過程

　　① 瀏覽器發送一個串連請求給安全伺服器。 

　　② 伺服器將自己的認證，以及同認證相關的資訊發送給客戶瀏覽器。 

　　③ 客戶瀏覽器檢查伺服器送過來的認證是否是由自己信賴的 CA 中心所簽發的。如果是，就繼續執行協議；如果不是，客戶瀏覽器就給客戶一個警告訊息：警告客戶這個認證不是可以信賴的，詢問客戶是否需要繼續。

　　④ 接著客戶瀏覽器比較認證裡的訊息，例如網域名稱和公開金鑰，與伺服器剛剛發送的相關訊息是否一致，如果是一致的，客戶瀏覽器認可這個伺服器的合法身份。 

 

　　⑤ 伺服器要求客戶發送客戶自己的認證。收到後，伺服器驗證客戶的認證，如果沒有通過驗證，拒絕串連；如果通過驗證，伺服器獲得使用者的公開金鑰。 

　　⑥ 客戶瀏覽器告訴伺服器自己所能夠支援的通訊對稱密碼方案。

　　⑦ 伺服器從客戶發送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公開金鑰加過密後通知瀏覽器。

　　⑧ 瀏覽器針對這個密碼方案，選擇一個通話密鑰，接著用伺服器的公開金鑰加過密後發送給伺服器。

　　⑨ 伺服器接收到瀏覽器送過來的訊息，用自己的私密金鑰解密，獲得通話密鑰。 

　　⑩ 伺服器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱金鑰是加過密的。

 

上面所述的是雙向認證 SSL 協議的具體通訊過程，這種情況要求伺服器和使用者雙方都有認證。單向認證 SSL 協議不需要客戶擁有 CA 憑證，具體的過程相對於上面的步驟，只需將伺服器端驗證客戶認證的過程去掉，以及在協商對稱密碼方案，對稱通話密鑰時，伺服器發送給客戶的是沒有加過密的（這並不影響 SSL 過程的安全性）密碼方案。這樣，雙方具體的通訊內容，就是加過密的資料，如果有第三方攻擊，獲得的只是加密的資料，第三方要獲得有用的資訊，就需要對加密的資料進行解密，這時候的安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調要求使用 128 位加密通訊的原因。

SSL協議握手工作流程詳解(雙向HTTPS流程)