單向認(rèn)證

基于ssl充岛，一般的應(yīng)用都是單向認(rèn)證访诱，如果應(yīng)用場(chǎng)景要求對(duì)客戶來(lái)源做驗(yàn)證也可以實(shí)現(xiàn)成雙向認(rèn)證麻蹋。
為了便于更好的認(rèn)識(shí)和理解 SSL 協(xié)議赊琳，這里著重介紹 SSL 協(xié)議的握手協(xié)議街夭。SSL 協(xié)議既用到了公鑰加密技術(shù)又用到了對(duì)稱加密技術(shù)，對(duì)稱加密技術(shù)雖然比公鑰加密技術(shù)的速度快躏筏，可是公鑰加密技術(shù)提供了更好的身份認(rèn)證技術(shù)板丽。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)證

雙向認(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 位加密通訊的原因。

一般web應(yīng)用都是采用單向認(rèn)證的穿剖，原因很簡(jiǎn)單蚤蔓，用戶數(shù)目廣泛，且無(wú)需做在通訊層做用戶身份驗(yàn)證糊余，一般都在應(yīng)用邏輯層來(lái)保證用戶的合法登入秀又。
但如果是企業(yè)應(yīng)用對(duì)接，情況就不一樣贬芥，可能會(huì)要求對(duì)client（相對(duì)而言）做身份驗(yàn)證吐辙。這時(shí)需要做雙向認(rèn)證。