摘要：本文嘗試一步步還原HTTPS的設(shè)計過程，以理解為什么HTTPS最終會是這副模樣尺棋。但是這并不代表HTTPS的真實(shí)設(shè)計過程封锉。在閱讀本文時，你可以嘗試放下已有的對HTTPS的理解膘螟，這樣更利于“還原”過程成福。

我們先不了聊HTTP，HTTPS荆残，我們先從一個聊天軟件說起奴艾，我們要實(shí)現(xiàn)A能發(fā)一個hello消息給B：

如果我們要實(shí)現(xiàn)這個聊天軟件，本文只考慮安全性問題内斯，要實(shí)現(xiàn)

A發(fā)給B的hello消息包蕴潦，即使被中間人攔截到了像啼，也無法得知消息的內(nèi)容

如何做到真正的安全？

這個問題潭苞，很多人馬上就想到了各種加密算法忽冻，什么對稱加密、非對稱加密此疹、DES僧诚、RSA、XX蝗碎、噼里啪啦~

而我想說湖笨，加密算法只是解決方案，我們首先要做的是理解我們的問題域——什么是安全蹦骑？

我個人的理解是：

A與B通信的內(nèi)容慈省，有且只有A和B有能力看到通信的真正內(nèi)容

好，問題域已經(jīng)定義好了（現(xiàn)實(shí)中當(dāng)然不止這一種定義）眠菇。對于解決方案边败，很容易就想到了對消息進(jìn)行加密。

題外話琼锋，但是只有這一種方法嗎放闺？我看未必，說不定在將來會出現(xiàn)一種物質(zhì)打破當(dāng)前世界的通信假設(shè)缕坎，實(shí)現(xiàn)真正意義上的保密怖侦。

對于A與B這樣的簡單通信模型，我們很容易做出選擇：

這就是對稱加密算法谜叹，其中圖中的密鑰S同時扮演加密和解密的角色匾寝。具體細(xì)節(jié)不是本文范疇。

只要這個密鑰S不公開給第三者荷腊，同時密鑰S足夠安全艳悔，我們就解決了我們一開始所定問題域了。因?yàn)槭澜缟嫌星抑挥蠥與B知道如何加密和解密他們之間的消息女仰。

但是猜年，在WWW環(huán)境下，我們的Web服務(wù)器的通信模型沒有這么簡單：

如果服務(wù)器端對所有的客戶端通信都使用同樣的對稱加密算法疾忍，無異于沒有加密乔外。那怎么辦呢？即能使用對稱加密算法一罩，又不公開密鑰杨幼？請讀者思考21秒鐘。??

答案是：Web服務(wù)器與每個客戶端使用不同的對稱加密算法：

如何確定對稱加密算法

慢著，另一個問題來了差购，我們的服務(wù)器端怎么告訴客戶端該使用哪種對稱加密算法四瘫？
當(dāng)然是通過協(xié)商。

但是，你協(xié)商的過程是沒有加密的，還是會被中間人攔截唆阿。那我們再對這個協(xié)商過程進(jìn)行對稱加密就好了，那你對協(xié)商過程加密的加密還是沒有加密锹杈，怎么辦撵孤？再加密不就好了……好吧迈着，進(jìn)行雞生蛋蛋生雞的問題了。

如何對協(xié)商過程進(jìn)行加密

新問題來了邪码，如何對協(xié)商過程進(jìn)行加密裕菠？密碼學(xué)領(lǐng)域中，有一種稱為“非對稱加密”的加密算法闭专，特點(diǎn)是私鑰加密后的密文奴潘，只要是公鑰，都可以解密影钉，但是公鑰加密后的密文画髓，只有私鑰可以解密。私鑰只有一個人有平委，而公鑰可以發(fā)給所有的人奈虾。

雖然服務(wù)器端向A、B……的方向還是不安全的廉赔，但是至少A肉微、B向服務(wù)器端方向是安全的。

好了蜡塌，如何協(xié)商加密算法的問題碉纳，我們解決了：使用非對稱加密算法進(jìn)行對稱加密算法協(xié)商過程。

這下馏艾，你明白為什么HTTPS同時需要對稱加密算法和非對稱加密算法了吧劳曹？

協(xié)商什么加密算法

要達(dá)到Web服務(wù)器針對每個客戶端使用不同的對稱加密算法，同時琅摩，我們也不能讓第三者知道這個對稱加密算法是什么铁孵，怎么辦？

使用隨機(jī)數(shù)迫吐，就是使用隨機(jī)數(shù)來生成對稱加密算法库菲。這樣就可以做到服務(wù)器和客戶端每次交互都是新的加密算法、只有在交互的那一該才確定加密算法志膀。

這下熙宇，你明白為什么HTTPS協(xié)議握手階段會有這么多的隨機(jī)數(shù)了吧鳖擒。

如何得到公鑰？

細(xì)心的人可能已經(jīng)注意到了如果使用非對稱加密算法烫止，我們的客戶端A蒋荚，B需要一開始就持有公鑰，要不沒法開展加密行為啊馆蠕。

這下期升，我們又遇到新問題了，如何讓A互躬、B客戶端安全地得到公鑰播赁？

我能想到的方案只有這些：

方案1. 服務(wù)器端將公鑰發(fā)送給每一個客戶端
方案2. 服務(wù)器端將公鑰放到一個遠(yuǎn)程服務(wù)器，客戶端可以請求得到

我們選擇方案1吼渡，因?yàn)榉桨?又多了一次請求容为，還要另外處理公鑰的放置問題。

公鑰被調(diào)包了怎么辦寺酪？又是一個雞生蛋蛋生雞問題坎背？

但是方案1有個問題：如果服務(wù)器端發(fā)送公鑰給客戶端時，被中間人調(diào)包了寄雀，怎么辦得滤？

我畫了張圖方便理解：

顯然，讓每個客戶端的每個瀏覽器默認(rèn)保存所有網(wǎng)站的公鑰是不現(xiàn)實(shí)的盒犹。

使用第三方機(jī)構(gòu)的公鑰解決雞生蛋蛋生雞問題

公鑰被調(diào)包的問題出現(xiàn)懂更，是因?yàn)槲覀兊目蛻舳藷o法分辨返回公鑰的人到底是中間人，還是真的服務(wù)器阿趁。這其實(shí)就是密碼學(xué)中提的身份驗(yàn)證問題膜蛔。

如果讓你來解決，你怎么解決脖阵？如果你了解過HTTPS皂股，會知道使用數(shù)字證書來解決。但是你想過證書的本質(zhì)是什么么命黔？請放下你對HTTPS已有的知識呜呐，自己嘗試找到解決方案。

我是這樣解決的悍募。既然服務(wù)器需要將公鑰傳給客戶端蘑辑，這個過程本身是不安全，那么我們?yōu)槭裁床粚@個過程本身再加密一次坠宴？可是洋魂，你是使用對稱加密，還是非對稱加密？這下好了副砍，我感覺又進(jìn)了雞生蛋蛋生雞問題了衔肢。

問題的難點(diǎn)是如果我們選擇直接將公鑰傳遞給客戶端的方案，我們始終無法解決公鑰傳遞被中間人調(diào)包的問題豁翎。

所以角骤，我們不能直接將服務(wù)器的公鑰傳遞給客戶端，而是第三方機(jī)構(gòu)使用它的私鑰對我們的公鑰進(jìn)行加密后心剥，再傳給客戶端邦尊。客戶端再使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密优烧。

下圖就是我們設(shè)計的第一版“數(shù)字證書”蝉揍，證書中只有服務(wù)器交給第三方機(jī)構(gòu)的公鑰，而且這個公鑰被第三方機(jī)構(gòu)的私鑰加密了：

如果能解密匙隔，就說明這個公鑰沒有被中間人調(diào)包疑苫。因?yàn)槿绻虚g人使用自己的私鑰加密后的東西傳給客戶端，客戶端是無法使用第三方的公鑰進(jìn)行解密的纷责。

話到此，我以為解決問題了撼短。但是現(xiàn)實(shí)中HTTPS再膳，還有一個數(shù)字簽名的概念，我沒法理解它的設(shè)計理由曲横。

原來喂柒，我漏掉了一個場景：第三方機(jī)構(gòu)不可能只給你一家公司制作證書，它也可能會給中間人這樣有壞心思的公司發(fā)放證書禾嫉。這樣的灾杰，中間人就有機(jī)會對你的證書進(jìn)行調(diào)包，客戶端在這種情況下是無法分辨出是接收的是你的證書熙参，還是中間人的艳吠。因?yàn)椴徽撝虚g人，還是你的證書孽椰，都能使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密昭娩。像下面這樣：

第三方機(jī)構(gòu)向多家公司頒發(fā)證書的情況：

客戶端能解密同一家第三機(jī)構(gòu)頒發(fā)的所有證書：

最終導(dǎo)致其它持有同一家第三方機(jī)構(gòu)證書的中間人可以進(jìn)行調(diào)包：

數(shù)字簽名，解決同一機(jī)構(gòu)頒發(fā)的不同證書被篡改問題

要解決這個問題黍匾，我們首先要想清楚一個問題栏渺，辨別同一機(jī)構(gòu)下不同證書的這個職責(zé)，我們應(yīng)該放在哪锐涯？

只能放到客戶端了磕诊。意思是，客戶端在拿到證書后，自己就有能力分辨證書是否被篡改了霎终。如何才能有這個能力呢融痛？

我們從現(xiàn)實(shí)中找靈感。比如你是HR神僵，你手上拿到候選人的學(xué)歷證書雁刷，證書上寫了持證人，頒發(fā)機(jī)構(gòu)保礼，頒發(fā)時間等等沛励，同時證書上，還寫有一個最重要的：證書編號炮障！我們怎么鑒別這張證書是的真?zhèn)文啬颗桑恐灰弥@個證書編號上相關(guān)機(jī)構(gòu)去查，如果證書上的持證人與現(xiàn)實(shí)的這個候選人一致胁赢，同時證書編號也能對應(yīng)上企蹭，那么就說明這個證書是真實(shí)的。

我們的客戶端能不能采用這個機(jī)制呢智末？像這樣：

可是谅摄，這個“第三方機(jī)構(gòu)”到底是在哪呢？是一個遠(yuǎn)端服務(wù)系馆？不可能吧送漠？如果是個遠(yuǎn)端服務(wù)，整個交互都會慢了由蘑。所以闽寡，這個第三方機(jī)構(gòu)的驗(yàn)證功能只能放在客戶端的本地了。

客戶端本地怎么驗(yàn)證證書呢尼酿？

客戶端本地怎么驗(yàn)證證書呢爷狈？答案是證書本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書的真?zhèn)巍?/p>

也就是證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號∩亚妫客戶端拿到證書后根據(jù)證書上的方法自己生成一個證書編號涎永，如果生成的證書編號與證書上的證書編號相同，那么說明這個證書是真實(shí)的句惯。

同時土辩，為避免證書編號本身又被調(diào)包，所以使用第三方的私鑰進(jìn)行加密抢野。

這地方有些抽象拷淘，我們來個圖幫助理解：

證書的制作如圖所示。證書中的“編號生成方法MD5”就是告訴客戶端：你使用MD5對證書的內(nèi)容求值就可以得到一個證書編號指孤。

當(dāng)客戶端拿到證書后启涯，開始對證書中的內(nèi)容進(jìn)行驗(yàn)證贬堵，如果客戶端計算出來的證書編號與證書中的證書編號相同，則驗(yàn)證通過：

但是第三方機(jī)構(gòu)的公鑰怎么跑到了客戶端的機(jī)器中呢结洼？世界上這么多機(jī)器黎做。

其實(shí)呢，現(xiàn)實(shí)中松忍，瀏覽器和操作系統(tǒng)都會維護(hù)一個權(quán)威的第三方機(jī)構(gòu)列表（包括它們的公鑰）蒸殿。因?yàn)榭蛻舳私邮盏降淖C書中會寫有頒發(fā)機(jī)構(gòu)，客戶端就根據(jù)這個頒發(fā)機(jī)構(gòu)的值在本地找相應(yīng)的公鑰鸣峭。

題外話：如果瀏覽器和操作系統(tǒng)這道防線被破了宏所，就沒辦法。想想當(dāng)年自己裝過的非常規(guī)XP系統(tǒng)摊溶，都害怕爬骤。

說到這里，想必大家已經(jīng)知道上文所說的莫换，證書就是HTTPS中數(shù)字證書霞玄，證書編號就是數(shù)字簽名，而第三方機(jī)構(gòu)就是指數(shù)字證書簽發(fā)機(jī)構(gòu)（CA）拉岁。

CA如何頒發(fā)數(shù)字證書給服務(wù)器端的坷剧？

當(dāng)我聽到這個問題時，我誤以為膛薛，我們的SERVER需要發(fā)網(wǎng)絡(luò)請求到CA部門的服務(wù)器來拿這個證書听隐。?? 到底是我理解能力問題，還是哄啄。。

其實(shí)风范，問題應(yīng)該是CA如何頒發(fā)給我們的網(wǎng)站管理員咨跌，而我們的管理員又如何將這個數(shù)字證書放到我們的服務(wù)器上。

我們?nèi)绾蜗駽A申請呢硼婿？每個CA機(jī)構(gòu)都大同小異锌半，我在網(wǎng)上找了一個：

拿到證書后，我們就可以將證書配置到自己的服務(wù)器上了寇漫。那么如何配置刊殉？這是具體細(xì)節(jié)了，留給大家google了州胳。

也許我們需要整理一下思路

我們通過推算的方式嘗試還原HTTPS的設(shè)計過程记焊。這樣，我們也就明白了為什么HTTPS比HTTP多那么多次的交互栓撞，為什么HTTPS的性能會差遍膜，以及找到HTTPS的性能優(yōu)化點(diǎn)碗硬。

而上面一大堆工作都是為了讓客戶端與服務(wù)器端安全地協(xié)商出一個對稱加密算法。這就是HTTPS中的SSL/TLS協(xié)議主要干的活瓢颅。剩下的就是通信時雙方使用這個對稱加密算法進(jìn)行加密解密恩尾。

以下是一張HTTPS協(xié)議的真實(shí)交互圖（從網(wǎng)上copy的，忘了從哪了挽懦，如果侵權(quán)麻煩告知）：

能不能用一句話總結(jié)HTTPS翰意？

答案是不能，因?yàn)镠TTPS本身實(shí)在太復(fù)雜信柿。但是我還是嘗試使用一段話來總結(jié)HTTPS:

HTTPS要使客戶端與服務(wù)器端的通信過程得到安全保證冀偶，必須使用的對稱加密算法，但是協(xié)商對稱加密算法的過程角塑，需要使用非對稱加密算法來保證安全蔫磨，然而直接使用非對稱加密的過程本身也不安全，會有中間人篡改公鑰的可能性圃伶，所以客戶端與服務(wù)器不直接使用公鑰堤如，而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來保證非對稱加密過程本身的安全。這樣通過這些機(jī)制協(xié)商出一個對稱加密算法窒朋，就此雙方使用該算法進(jìn)行加密解密搀罢。從而解決了客戶端與服務(wù)器端之間的通信安全問題。

好長的一段話侥猩。

后記

以上是個人為理解HTTPS而編造出來的自圓其說的看法榔至。頂多只能算是HTTPS的科普文章。如有錯誤欺劳，請指出唧取，萬分感謝。

那么划提，我為什么會覺得以這種方式理解HTTPS會更容易呢枫弟？我個人給出的答案是：當(dāng)你自己為一家人做一次菜時，你就會理解媽媽天天做菜的不易了鹏往。

學(xué)習(xí)資料：

• HTTPS為什么安全 &分析 HTTPS 連接建立全過程

• 數(shù)字證書的基礎(chǔ)知識

• 理解 HTTPS

• HTTPS 是如何保證安全的淡诗？

• 圖解SSL/TLS協(xié)議

• The First Few Milliseconds of an HTTPS Connection

• SSL/TLS原理詳解

作者：翟志軍
showme.codes/2017-02-20/understand-https/

對數(shù)字簽名還有疑惑的小伙伴，可以看以下的漫畫理解伊履。

什么是數(shù)字簽名韩容？

鮑勃有兩把鑰匙，一把是公鑰唐瀑，另一把是私鑰群凶。

鮑勃把公鑰送給他的朋友們----帕蒂、道格介褥、蘇珊----每人一把座掘。

蘇珊要給鮑勃寫一封保密的信递惋。她寫完后用鮑勃的公鑰加密，就可以達(dá)到保密的效果溢陪。

鮑勃收信后萍虽，用私鑰解密，就看到了信件內(nèi)容形真。這里要強(qiáng)調(diào)的是杉编，只要鮑勃的私鑰不泄露，這封信就是安全的咆霜，即使落在別人手里邓馒，也無法解密。

鮑勃給蘇珊回信蛾坯，決定采用"數(shù)字簽名"光酣。他寫完后先用Hash函數(shù)，生成信件的摘要（digest）脉课。

然后救军，鮑勃使用私鑰，對這個摘要加密倘零，生成"數(shù)字簽名"（signature）唱遭。

鮑勃將這個簽名，附在信件下面呈驶，一起發(fā)給蘇珊拷泽。

蘇珊收信后，取下數(shù)字簽名袖瞻，用鮑勃的公鑰解密司致，得到信件的摘要。由此證明聋迎，這封信確實(shí)是鮑勃發(fā)出的蚌吸。

蘇珊再對信件本身使用Hash函數(shù)，將得到的結(jié)果砌庄，與上一步得到的摘要進(jìn)行對比。如果兩者一致奕枢，就證明這封信未被修改過娄昆。

復(fù)雜的情況出現(xiàn)了。道格想欺騙蘇珊缝彬，他偷偷使用了蘇珊的電腦萌焰，用自己的公鑰換走了鮑勃的公鑰。此時谷浅，蘇珊實(shí)際擁有的是道格的公鑰扒俯，但是還以為這是鮑勃的公鑰奶卓。因此，道格就可以冒充鮑勃撼玄，用自己的私鑰做成"數(shù)字簽名"夺姑，寫信給蘇珊，讓蘇珊用假的鮑勃公鑰進(jìn)行解密掌猛。

后來盏浙，蘇珊感覺不對勁，發(fā)現(xiàn)自己無法確定公鑰是否真的屬于鮑勃荔茬。她想到了一個辦法废膘，要求鮑勃去找"證書中心"（certificate authority，簡稱CA）慕蔚，為公鑰做認(rèn)證丐黄。證書中心用自己的私鑰，對鮑勃的公鑰和一些相關(guān)信息一起加密孔飒，生成"數(shù)字證書"（Digital Certificate）灌闺。

鮑勃拿到數(shù)字證書以后，就可以放心了十偶。以后再給蘇珊寫信菩鲜，只要在簽名的同時，再附上數(shù)字證書就行了惦积。

蘇珊收信后接校，用CA的公鑰解開數(shù)字證書，就可以拿到鮑勃真實(shí)的公鑰了狮崩，然后就能證明"數(shù)字簽名"是否真的是鮑勃簽的蛛勉。

下面，我們看一個應(yīng)用"數(shù)字證書"的實(shí)例：https協(xié)議睦柴。這個協(xié)議主要用于網(wǎng)頁加密诽凌。

首先，客戶端向服務(wù)器發(fā)出加密請求坦敌。

服務(wù)器用自己的私鑰加密網(wǎng)頁以后侣诵，連同本身的數(shù)字證書，一起發(fā)送給客戶端狱窘。

客戶端（瀏覽器）的"證書管理器"杜顺，有"受信任的根證書頒發(fā)機(jī)構(gòu)"列表≌赫ǎ客戶端會根據(jù)這張列表躬络，查看解開數(shù)字證書的公鑰是否在列表之內(nèi)。

如果數(shù)字證書記載的網(wǎng)址搭儒，與你正在瀏覽的網(wǎng)址不一致穷当，就說明這張證書可能被冒用提茁，瀏覽器會發(fā)出警告。

如果這張數(shù)字證書不是由受信任的機(jī)構(gòu)頒發(fā)的馁菜，瀏覽器會發(fā)出另一種警告茴扁。

如果數(shù)字證書是可靠的，客戶端就可以使用證書中的服務(wù)器公鑰火邓，對信息進(jìn)行加密丹弱，然后與服務(wù)器交換加密信息。
（完）