SSL 協議 (HTTPS) 握手、工作流程詳解 (雙向 HTTPS 流程 )
SSL 協議的工作流程:
服務器認證階段:
1)客戶端向服務器發送一個開始信息“Hello”以便開始一個新的會話連接;
2)服務器根據客戶的信息確定是否需要生成新的主密鑰,如需要則服務器在響應客戶的“Hello”信息時將包含生成主密鑰所需的信息;
3)客戶根據收到的服務器響應信息,產生一個主密鑰,並用服務器的公開密鑰加密後傳給服務器;
4)服務器恢復該主密鑰,並返回給客戶一個用主密鑰認證的信息,以此讓客戶認證服務器。
用戶認證階段:在此之前,服務器已經通過了客戶認證,這一階段主要完成對客戶的認證。經認證的
服務器發送一個提問給客戶,客戶則返回(數字)簽名後的提問和其公開密鑰,從而向服務器提供認證。
從 SSL 協議所提供的服務及其工作流程可以看出,SSL 協議運行的基礎是商家對消費者信息保密的
承諾,這就有利於商家而不利於消費者。在電子商務初級階段,由於運作電子商務的企業大多是信譽較
高的大公司,因此這問題還沒有充分暴露出來。但隨着電子商務的發展,各中小型公司也參與進來, 這
樣在電子支付過程中的單一認證問題就越來越突出。雖然在 SSL3.0 中通過數字簽名和數字證書可實現瀏覽器和 Web 服務器雙方的身份驗證,但是 SSL 協 議仍存在一些問題,比如,只能提供交易中客戶與服
務器間的雙方認證,在涉及多方的電子交易中,SSL 協議並不能協調各方間的安全傳輸和信任關係。在
這種情 況下,Visa 和 MasterCard 兩大信用卡公組織制定了 SET 協議,爲網上信用卡支付提供了全球
性的標準。
SSL 協議的握手過程
爲了便於更好的認識和理解 SSL 協議,這裏着重介紹 SSL 協議的握手協議。SSL 協議既用到了公
鑰加密技術(非對稱加密)又用到了對稱加密技術,SSL 對傳輸內容的加密是採用的對稱加密,然後對對
稱加密的密鑰使用公鑰進行非對稱加密。這樣做的好處是,對稱加密技術比公鑰加密技術的速度快,可
用來加密較大的傳輸內容, 公鑰加密技術相對較慢,提供了更好的身份認證技術,可用來加密對稱加密
過程使用的密鑰。
SSL 的握手協議非常有效的讓客戶和服務器之間完成相互之間的身份認證,其主要過程如下:
1客戶端的瀏覽器向服務器傳送客戶端 SSL 協議的版本號,加密算法的種類,產生的隨機數,以及
其他服務器和客戶端之間通訊所需要的各種信息。
2服務器向客戶端傳送 SSL 協議的版本號,加密算法的種類,隨機數以及其他相關信息,同時服務
器還將向客戶端傳送自己的證書。
3客戶利用服務器傳過來的信息驗證服務器的合法性,服務器的合法性包括:證書是否過期,發行
服務器證書的 CA 是否可靠,發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”,服務器
證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過,通訊將斷開;如果合法性驗
證通過,將繼續進行第四步。
4用戶端隨機產生一個用於後面通訊的“對稱密碼”,然後用服務器的公鑰(服務器的公鑰從步驟2中
的服務器的證書中獲得)對其加密,然後將加密後的“預主密碼”傳給服務器。
5如果服務器要求客戶的身份認證(在握手過程中爲可選),用戶可以建立一個隨機數然後對其進
行數據簽名,將這個含有簽名的隨機數和客戶自己的證書以及加密過的“預主密碼”一起傳給服務器。
6如果服務器要求客戶的身份認證,服務器必須檢驗客戶證書和簽名隨機數的合 法性,具體的合法
性驗證過程包括:客戶的證書使用日期是否有效,爲客戶提供證書的 CA 是否可靠,發行 CA 的公鑰能
否正確解開客戶證書的發行 CA 的數字簽名,檢查客戶的證書是否在證書廢止列表(CRL)中。檢驗如
果沒有通過,通訊立刻中斷;如果驗證通過,服務器將用自己的私鑰解開加密的“預主密碼 ”,然後執行
一系列步驟來產生主通訊密碼(客戶端也將通過同樣的方法產生相同的主通訊密碼)。
7服務器和客戶端用相同的主密碼即“通話密碼”,一個對稱密鑰用於 SSL 協議的安全數據通訊的加
解密通訊。同時在 SSL 通訊過程中還要完成數據通訊的完整性,防止數據通訊中的任何變化。
8客戶端向服務器端發出信息,指明後面的數據通訊將使用的步驟7中的主密碼爲對稱密鑰,同時
通知服務器客戶端的握手過程結束。
9服務器向客戶端發出信息,指明後面的數據通訊將使用的步驟7中的主密碼爲對稱密鑰,同時通
知客戶端服務器端的握手過程結束。
10 SSL 的握手部分結束,SSL 安全通道的數據通訊開始,客戶和服務器開始使用相同的對稱密鑰進
行數據通訊,同時進行通訊完整性的檢驗。
雙向認證 SSL 協議的具體過程
1 瀏覽器發送一個連接請求給安全服務器。
2 服務器將自己的證書,以及同證書相關的信息發送給客戶瀏覽器。
3 客戶瀏覽器檢查服務器送過來的證書是否是由自己信賴的 CA 中心所簽發的。如果是,就繼續執
行協議;如果不是,客戶瀏覽器就給客戶一個警告消息:警告客戶這個證書不是可以信賴的,詢問客戶
是否需要繼續。
4 接着客戶瀏覽器比較證書裏的消息,例如域名和公鑰,與服務器剛剛發送的相關消息是否一致,
如果是一致的,客戶瀏覽器認可這個服務器的合法身份。
5 服務器要求客戶發送客戶自己的證書。收到後,服務器驗證客戶的證書,如果沒有通過驗證,拒
絕連接;如果通過驗證,服務器獲得用戶的公鑰。
6 客戶瀏覽器告訴服務器自己所能夠支持的通訊對稱密碼方案。
7 服務器從客戶發送過來的密碼方案中,選擇一種加密程度最高的密碼方案,用客戶的公鑰加過密
後通知瀏覽器。
8 瀏覽器針對這個密碼方案,選擇一個通話密鑰,接着用服務器的公鑰加過密後發送給服務器。
9 服務器接收到瀏覽器送過來的消息,用自己的私鑰解密,獲得通話密鑰。
10 服務器、瀏覽器接下來的通訊都是用對稱密碼方案,對稱密鑰是加過密的。
上面所述的是雙向認證 SSL 協議的具體通訊過程,這種情況要求服務器和用戶雙方都有證書。單向
認證 SSL 協議不需要客戶擁有 CA 證書,具體的過程相對於上面的步驟,只需將服務器端驗證客戶證書
的過程去掉,以及在協商對稱密碼方案,對稱通話密鑰時,服務器發送給客戶的是沒有加過密的 (這並
不影響 SSL 過程的安全性)密碼方案。這樣,雙方具體的通訊內容,就是加過密的數據,如果有第三方
***,獲得的只是加密的數據,第三方要獲得有用的信息,就需要對加密 的數據進行解密,這時候的安
全就依賴於密碼方案的安全。而幸運的是,目前所用的密碼方案,只要通訊密鑰長度足夠的長,就足夠
的安全。這也是我們強調要求使 用 128 位加密通訊的原因。