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

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

?

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

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

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

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

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

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

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

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

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

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

?

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

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

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

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

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

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

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

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

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

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

　　上面所述的是雙向認(rèn)證 SSL 協(xié)議的具體通訊過(guò)程，這種情況要求服務(wù)器和用戶雙方都有證書(shū)。單向認(rèn)證 SSL 協(xié)議不需要客戶擁有 CA 證書(shū)，具體的過(guò)程相對(duì)于上面的步驟，只需將服務(wù)器端驗(yàn)證客戶證書(shū)的過(guò)程去掉，以及在協(xié)商對(duì)稱密碼方案，對(duì)稱通話密鑰時(shí)，服務(wù)器發(fā)送給客戶的是沒(méi)有加過(guò)密的（這并不影響 SSL 過(guò)程的安全性）密碼方案。這樣，雙方具體的通訊內(nèi)容，就是加過(guò)密的數(shù)據(jù)，如果有第三方攻擊，獲得的只是加密的數(shù)據(jù)，第三方要獲得有用的信息，就需要對(duì)加密的數(shù)據(jù)進(jìn)行解密，這時(shí)候的安全就依賴于密碼方案的安全。而幸運(yùn)的是，目前所用的密碼方案，只要通訊密鑰長(zhǎng)度足夠的長(zhǎng)，就足夠的安全。這也是我們強(qiáng)調(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流程)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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