SSL協(xié)議的工作流程：

????? 服務(wù)器認證階段：1）客戶端向服務(wù)器發(fā)送一個開始信息“Hello”以便開始一個新的會話連接；2）服務(wù)器根據(jù)客戶的信息確定是否需要生成新的主密鑰，如需要則服務(wù)器在響應(yīng)客戶的“Hello”信息時將包含生成主密鑰所需的信息；3）客戶根據(jù)收到的服務(wù)器響應(yīng)信息，產(chǎn)生一個主密鑰，并用服務(wù)器的公開密鑰加密后傳給服務(wù)器；4）服務(wù)器恢復(fù)該主密鑰，并返回給客戶一個用主密鑰認證的信息，以此讓客戶認證服務(wù)器。
????? 用戶認證階段：在此之前，服務(wù)器已經(jīng)通過了客戶認證，這一階段主要完成對客戶的認證。經(jīng)認證的服務(wù)器發(fā)送一個提問給客戶，客戶則返回（數(shù)字）簽名后的提問和其公開密鑰，從而向服務(wù)器提供認證。
????? 從SSL 協(xié)議所提供的服務(wù)及其工作流程可以看出，SSL協(xié)議運行的基礎(chǔ)是商家對消費者信息保密的承諾，這就有利于商家而不利于消費者。在電子商務(wù)初級階段，由于運作電子商務(wù)的企業(yè)大多是信譽較高的大公司，因此這問題還沒有充分暴露出來。但隨著電子商務(wù)的發(fā)展，各中小型公司也參與進來，這樣在電子支付過程中的單一認證問題就越來越突出。雖然在SSL3.0中通過數(shù)字簽名和數(shù)字證書可實現(xiàn)瀏覽器和Web服務(wù)器雙方的身份驗證，但是SSL協(xié)議仍存在一些問題，比如，只能提供交易中客戶與服務(wù)器間的雙方認證，在涉及多方的電子交易中，SSL協(xié)議并不能協(xié)調(diào)各方間的安全傳輸和信任關(guān)系。在這種情況下，Visa和 MasterCard兩大信用卡公組織制定了SET協(xié)議，為網(wǎng)上信用卡支付提供了全球性的標準。

?

SSL協(xié)議的握手過程?　　

????? 為了便于更好的認識和理解 SSL 協(xié)議，這里著重介紹 SSL 協(xié)議的握手協(xié)議。SSL 協(xié)議既用到了公鑰加密技術(shù)(非對稱加密)又用到了對稱加密技術(shù)，SSL對傳輸內(nèi)容的加密是采用的對稱加密，然后對對稱加密的密鑰使用公鑰進行非對稱加密。這樣做的好處是，對稱加密技術(shù)比公鑰加密技術(shù)的速度快，可用來加密較大的傳輸內(nèi)容， 公鑰加密技術(shù)相對較慢，提供了更好的身份認證技術(shù)，可用來加密對稱加密過程使用的密鑰。
????? SSL 的握手協(xié)議非常有效的讓客戶和服務(wù)器之間完成相互之間的身份認證，其主要過程如下：
　　①客戶端的瀏覽器向服務(wù)器傳送客戶端 SSL 協(xié)議的版本號，加密算法的種類，產(chǎn)生的隨機數(shù)，以及其他服務(wù)器和客戶端之間通訊所需要的各種信息。

　　②服務(wù)器向客戶端傳送 SSL 協(xié)議的版本號，加密算法的種類，隨機數(shù)以及其他相關(guān)信息，同時服務(wù)器還將向客戶端傳送自己的證書。

　　③客戶利用服務(wù)器傳過來的信息驗證服務(wù)器的合法性，服務(wù)器的合法性包括：證書是否過期，發(fā)行服務(wù)器證書的 CA 是否可靠，發(fā)行者證書的公鑰能否正確解開服務(wù)器證書的“發(fā)行者的數(shù)字簽名”，服務(wù)器證書上的域名是否和服務(wù)器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；如果合法性驗證通過，將繼續(xù)進行第四步。

　　④用戶端隨機產(chǎn)生一個用于后面通訊的“對稱密碼”，然后用服務(wù)器的公鑰（服務(wù)器的公鑰從步驟②中的服務(wù)器的證書中獲得）對其加密，然后將加密后的“預(yù)主密碼”傳給服務(wù)器。

　　⑤如果服務(wù)器要求客戶的身份認證（在握手過程中為可選），用戶可以建立一個隨機數(shù)然后對其進行數(shù)據(jù)簽名，將這個含有簽名的隨機數(shù)和客戶自己的證書以及加密過的“預(yù)主密碼”一起傳給服務(wù)器。

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

　　⑦服務(wù)器和客戶端用相同的主密碼即“通話密碼”，一個對稱密鑰用于 SSL 協(xié)議的安全數(shù)據(jù)通訊的加解密通訊。同時在 SSL 通訊過程中還要完成數(shù)據(jù)通訊的完整性，防止數(shù)據(jù)通訊中的任何變化。

　　⑧客戶端向服務(wù)器端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知服務(wù)器客戶端的握手過程結(jié)束。

　　⑨服務(wù)器向客戶端發(fā)出信息，指明后面的數(shù)據(jù)通訊將使用的步驟⑦中的主密碼為對稱密鑰，同時通知客戶端服務(wù)器端的握手過程結(jié)束。
　　⑩SSL 的握手部分結(jié)束，SSL 安全通道的數(shù)據(jù)通訊開始，客戶和服務(wù)器開始使用相同的對稱密鑰進行數(shù)據(jù)通訊，同時進行通訊完整性的檢驗。

?

雙向認證 SSL 協(xié)議的具體過程
　　①?瀏覽器發(fā)送一個連接請求給安全服務(wù)器。

　　②?服務(wù)器將自己的證書，以及同證書相關(guān)的信息發(fā)送給客戶瀏覽器。

　　③?客戶瀏覽器檢查服務(wù)器送過來的證書是否是由自己信賴的 CA 中心所簽發(fā)的。如果是，就繼續(xù)執(zhí)行協(xié)議；如果不是，客戶瀏覽器就給客戶一個警告消息：警告客戶這個證書不是可以信賴的，詢問客戶是否需要繼續(xù)。

　　④?接著客戶瀏覽器比較證書里的消息，例如域名和公鑰，與服務(wù)器剛剛發(fā)送的相關(guān)消息是否一致，如果是一致的，客戶瀏覽器認可這個服務(wù)器的合法身份。

　　⑤?服務(wù)器要求客戶發(fā)送客戶自己的證書。收到后，服務(wù)器驗證客戶的證書，如果沒有通過驗證，拒絕連接；如果通過驗證，服務(wù)器獲得用戶的公鑰。

　　⑥?客戶瀏覽器告訴服務(wù)器自己所能夠支持的通訊對稱密碼方案。

　　⑦?服務(wù)器從客戶發(fā)送過來的密碼方案中，選擇一種加密程度最高的密碼方案，用客戶的公鑰加過密后通知瀏覽器。

　　⑧?瀏覽器針對這個密碼方案，選擇一個通話密鑰，接著用服務(wù)器的公鑰加過密后發(fā)送給服務(wù)器。

　　⑨?服務(wù)器接收到瀏覽器送過來的消息，用自己的私鑰解密，獲得通話密鑰。

　　⑩?服務(wù)器、瀏覽器接下來的通訊都是用對稱密碼方案，對稱密鑰是加過密的。

　　上面所述的是雙向認證 SSL 協(xié)議的具體通訊過程，這種情況要求服務(wù)器和用戶雙方都有證書。單向認證 SSL 協(xié)議不需要客戶擁有 CA 證書，具體的過程相對于上面的步驟，只需將服務(wù)器端驗證客戶證書的過程去掉，以及在協(xié)商對稱密碼方案，對稱通話密鑰時，服務(wù)器發(fā)送給客戶的是沒有加過密的（這并不影響 SSL 過程的安全性）密碼方案。這樣，雙方具體的通訊內(nèi)容，就是加過密的數(shù)據(jù)，如果有第三方攻擊，獲得的只是加密的數(shù)據(jù)，第三方要獲得有用的信息，就需要對加密的數(shù)據(jù)進行解密，這時候的安全就依賴于密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通訊密鑰長度足夠的長，就足夠的安全。這也是我們強調(diào)要求使用 128 位加密通訊的原因。

http://www.cnblogs.com/jifeng/archive/2010/11/30/1891779.html

轉(zhuǎn)載于:https://www.cnblogs.com/kungfupanda/p/4631005.html

總結(jié)

以上是生活随笔為你收集整理的SSL协议(HTTPS) 握手、工作流程详解(双向HTTPS流程)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。