【轉(zhuǎn)自】也許厉熟，這樣理解HTTPS更容易
摘要：本文嘗試一步步還原HTTPS的設(shè)計(jì)過(guò)程，以理解為什么HTTPS最終會(huì)是這副模樣较幌。但是這并不代表HTTPS的真實(shí)設(shè)計(jì)過(guò)程揍瑟。在閱讀本文時(shí)，你可以嘗試放下已有的對(duì)HTTPS的理解乍炉，這樣更利于“還原”過(guò)程绢片。
我們先不了聊HTTP，HTTPS岛琼，我們先從一個(gè)聊天軟件說(shuō)起底循，我們要實(shí)現(xiàn)A能發(fā)一個(gè)hello消息給B：
如果我們要實(shí)現(xiàn)這個(gè)聊天軟件，本文只考慮安全性問(wèn)題衷恭，要實(shí)現(xiàn)
A發(fā)給B的hello消息包此叠，即使被中間人攔截到了，也無(wú)法得知消息的內(nèi)容
如何做到真正的安全随珠？
這個(gè)問(wèn)題，很多人馬上就想到了各種加密算法猬错，什么對(duì)稱加密窗看、非對(duì)稱加密、DES倦炒、RSA显沈、XX、噼里啪啦~
而我想說(shuō)逢唤，加密算法只是解決方案拉讯，我們首先要做的是理解我們的問(wèn)題域——什么是安全？
我個(gè)人的理解是：
A與B通信的內(nèi)容鳖藕，有且只有A和B有能力看到通信的真正內(nèi)容
好魔慷，問(wèn)題域已經(jīng)定義好了（現(xiàn)實(shí)中當(dāng)然不止這一種定義）。對(duì)于解決方案著恩，很容易就想到了對(duì)消息進(jìn)行加密院尔。
題外話，但是只有這一種方法嗎喉誊？我看未必邀摆，說(shuō)不定在將來(lái)會(huì)出現(xiàn)一種物質(zhì)打破當(dāng)前世界的通信假設(shè)，實(shí)現(xiàn)真正意義上的保密伍茄。
對(duì)于A與B這樣的簡(jiǎn)單通信模型栋盹，我們很容易做出選擇：
這就是對(duì)稱加密算法，其中圖中的密鑰S同時(shí)扮演加密和解密的角色敷矫。具體細(xì)節(jié)不是本文范疇例获。
只要這個(gè)密鑰S不公開給第三者音念，同時(shí)密鑰S足夠安全，我們就解決了我們一開始所定問(wèn)題域了躏敢。因?yàn)槭澜缟嫌星抑挥蠥與B知道如何加密和解密他們之間的消息闷愤。
但是，在WWW環(huán)境下件余，我們的Web服務(wù)器的通信模型沒(méi)有這么簡(jiǎn)單：
如果服務(wù)器端對(duì)所有的客戶端通信都使用同樣的對(duì)稱加密算法讥脐，無(wú)異于沒(méi)有加密。那怎么辦呢啼器？即能使用對(duì)稱加密算法旬渠，又不公開密鑰？請(qǐng)讀者思考21秒鐘端壳。??
答案是：Web服務(wù)器與每個(gè)客戶端使用不同的對(duì)稱加密算法：
如何確定對(duì)稱加密算法
慢著告丢，另一個(gè)問(wèn)題來(lái)了，我們的服務(wù)器端怎么告訴客戶端該使用哪種對(duì)稱加密算法损谦？
當(dāng)然是通過(guò)協(xié)商岖免。
但是，你協(xié)商的過(guò)程是沒(méi)有加密的照捡，還是會(huì)被中間人攔截颅湘。那我們?cè)賹?duì)這個(gè)協(xié)商過(guò)程進(jìn)行對(duì)稱加密就好了，那你對(duì)協(xié)商過(guò)程加密的加密還是沒(méi)有加密栗精，怎么辦闯参？再加密不就好了……好吧，進(jìn)行雞生蛋蛋生雞的問(wèn)題了悲立。
如何對(duì)協(xié)商過(guò)程進(jìn)行加密
新問(wèn)題來(lái)了鹿寨，如何對(duì)協(xié)商過(guò)程進(jìn)行加密？密碼學(xué)領(lǐng)域中薪夕，有一種稱為“非對(duì)稱加密”的加密算法脚草，特點(diǎn)是私鑰加密后的密文，只要是公鑰寥殖，都可以解密玩讳，但是公鑰加密后的密文，只有私鑰可以解密嚼贡。私鑰只有一個(gè)人有熏纯，而公鑰可以發(fā)給所有的人。
雖然服務(wù)器端向A粤策、B……的方向還是不安全的樟澜，但是至少A、B向服務(wù)器端方向是安全的。
好了秩贰，如何協(xié)商加密算法的問(wèn)題霹俺，我們解決了：使用非對(duì)稱加密算法進(jìn)行對(duì)稱加密算法協(xié)商過(guò)程。
這下毒费，你明白為什么HTTPS同時(shí)需要對(duì)稱加密算法和非對(duì)稱加密算法了吧丙唧？
協(xié)商什么加密算法
要達(dá)到Web服務(wù)器針對(duì)每個(gè)客戶端使用不同的對(duì)稱加密算法，同時(shí)觅玻，我們也不能讓第三者知道這個(gè)對(duì)稱加密算法是什么想际，怎么辦？
使用隨機(jī)數(shù)溪厘，就是使用隨機(jī)數(shù)來(lái)生成對(duì)稱加密算法胡本。這樣就可以做到服務(wù)器和客戶端每次交互都是新的加密算法、只有在交互的那一該才確定加密算法畸悬。
這下侧甫，你明白為什么HTTPS協(xié)議握手階段會(huì)有這么多的隨機(jī)數(shù)了吧。
如何得到公鑰蹋宦？
細(xì)心的人可能已經(jīng)注意到了如果使用非對(duì)稱加密算法披粟，我們的客戶端A，B需要一開始就持有公鑰妆档，要不沒(méi)法開展加密行為啊僻爽。
這下，我們又遇到新問(wèn)題了贾惦，如何讓A、B客戶端安全地得到公鑰敦捧？
我能想到的方案只有這些：
方案1. 服務(wù)器端將公鑰發(fā)送給每一個(gè)客戶端
方案2. 服務(wù)器端將公鑰放到一個(gè)遠(yuǎn)程服務(wù)器须板，客戶端可以請(qǐng)求得到
我們選擇方案1，因?yàn)榉桨?又多了一次請(qǐng)求兢卵，還要另外處理公鑰的放置問(wèn)題习瑰。
公鑰被調(diào)包了怎么辦？又是一個(gè)雞生蛋蛋生雞問(wèn)題秽荤？
但是方案1有個(gè)問(wèn)題：如果服務(wù)器端發(fā)送公鑰給客戶端時(shí)甜奄，被中間人調(diào)包了，怎么辦窃款？
我畫了張圖方便理解：
顯然课兄，讓每個(gè)客戶端的每個(gè)瀏覽器默認(rèn)保存所有網(wǎng)站的公鑰是不現(xiàn)實(shí)的。
使用第三方機(jī)構(gòu)的公鑰解決雞生蛋蛋生雞問(wèn)題
公鑰被調(diào)包的問(wèn)題出現(xiàn)晨继，是因?yàn)槲覀兊目蛻舳藷o(wú)法分辨返回公鑰的人到底是中間人烟阐，還是真的服務(wù)器。這其實(shí)就是密碼學(xué)中提的身份驗(yàn)證問(wèn)題。
如果讓你來(lái)解決蜒茄，你怎么解決唉擂？如果你了解過(guò)HTTPS，會(huì)知道使用數(shù)字證書來(lái)解決檀葛。但是你想過(guò)證書的本質(zhì)是什么么玩祟？請(qǐng)放下你對(duì)HTTPS已有的知識(shí)，自己嘗試找到解決方案屿聋。
我是這樣解決的空扎。既然服務(wù)器需要將公鑰傳給客戶端，這個(gè)過(guò)程本身是不安全胜臊，那么我們?yōu)槭裁床粚?duì)這個(gè)過(guò)程本身再加密一次勺卢？可是，你是使用對(duì)稱加密象对，還是非對(duì)稱加密黑忱？這下好了，我感覺(jué)又進(jìn)了雞生蛋蛋生雞問(wèn)題了勒魔。
問(wèn)題的難點(diǎn)是如果我們選擇直接將公鑰傳遞給客戶端的方案甫煞，我們始終無(wú)法解決公鑰傳遞被中間人調(diào)包的問(wèn)題。
所以冠绢，我們不能直接將服務(wù)器的公鑰傳遞給客戶端抚吠，而是第三方機(jī)構(gòu)使用它的私鑰對(duì)我們的公鑰進(jìn)行加密后，再傳給客戶端弟胀】Γ客戶端再使用第三方機(jī)構(gòu)的公鑰進(jìn)行解密。
下圖就是我們?cè)O(shè)計(jì)的第一版“數(shù)字證書”孵户，證書中只有服務(wù)器交給第三方機(jī)構(gòu)的公鑰萧朝，而且這個(gè)公鑰被第三方機(jī)構(gòu)的私鑰加密了：
如果能解密，就說(shuō)明這個(gè)公鑰沒(méi)有被中間人調(diào)包夏哭。因?yàn)槿绻虚g人使用自己的私鑰加密后的東西傳給客戶端检柬，客戶端是無(wú)法使用第三方的公鑰進(jìn)行解密的。
話到此竖配，我以為解決問(wèn)題了何址。但是現(xiàn)實(shí)中HTTPS，還有一個(gè)數(shù)字簽名的概念进胯，我沒(méi)法理解它的設(shè)計(jì)理由用爪。
原來(lái)，我漏掉了一個(gè)場(chǎng)景：第三方機(jī)構(gòu)不可能只給你一家公司制作證書龄减，它也可能會(huì)給中間人這樣有壞心思的公司發(fā)放證書项钮。這樣的，中間人就有機(jī)會(huì)對(duì)你的證書進(jìn)行調(diào)包，客戶端在這種情況下是無(wú)法分辨出是接收的是你的證書烁巫，還是中間人的署隘。因?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ā)的不同證書被篡改問(wèn)題
要解決這個(gè)問(wèn)題阿弃，我們首先要想清楚一個(gè)問(wèn)題诊霹，辨別同一機(jī)構(gòu)下不同證書的這個(gè)職責(zé)，我們應(yīng)該放在哪渣淳？
只能放到客戶端了脾还。意思是，客戶端在拿到證書后入愧，自己就有能力分辨證書是否被篡改了鄙漏。如何才能有這個(gè)能力呢？
我們從現(xiàn)實(shí)中找靈感棺蛛。比如你是HR怔蚌，你手上拿到候選人的學(xué)歷證書，證書上寫了持證人旁赊，頒發(fā)機(jī)構(gòu)桦踊，頒發(fā)時(shí)間等等，同時(shí)證書上终畅，還寫有一個(gè)最重要的：證書編號(hào)籍胯！我們?cè)趺磋b別這張證書是的真?zhèn)文兀恐灰弥@個(gè)證書編號(hào)上相關(guān)機(jī)構(gòu)去查离福，如果證書上的持證人與現(xiàn)實(shí)的這個(gè)候選人一致芒炼，同時(shí)證書編號(hào)也能對(duì)應(yīng)上，那么就說(shuō)明這個(gè)證書是真實(shí)的术徊。
我們的客戶端能不能采用這個(gè)機(jī)制呢？像這樣：
可是鲸湃，這個(gè)“第三方機(jī)構(gòu)”到底是在哪呢赠涮？是一個(gè)遠(yuǎn)端服務(wù)？不可能吧暗挑？如果是個(gè)遠(yuǎn)端服務(wù)笋除，整個(gè)交互都會(huì)慢了。所以炸裆，這個(gè)第三方機(jī)構(gòu)的驗(yàn)證功能只能放在客戶端的本地了垃它。
客戶端本地怎么驗(yàn)證證書呢？
客戶端本地怎么驗(yàn)證證書呢？答案是證書本身就已經(jīng)告訴客戶端怎么驗(yàn)證證書的真?zhèn)巍?/p>
也就是證書上寫著如何根據(jù)證書的內(nèi)容生成證書編號(hào)国拇÷迨罚客戶端拿到證書后根據(jù)證書上的方法自己生成一個(gè)證書編號(hào)，如果生成的證書編號(hào)與證書上的證書編號(hào)相同酱吝，那么說(shuō)明這個(gè)證書是真實(shí)的也殖。
同時(shí)，為避免證書編號(hào)本身又被調(diào)包务热，所以使用第三方的私鑰進(jìn)行加密忆嗜。
這地方有些抽象，我們來(lái)個(gè)圖幫助理解：
證書的制作如圖所示崎岂。證書中的“編號(hào)生成方法MD5”就是告訴客戶端：你使用MD5對(duì)證書的內(nèi)容求值就可以得到一個(gè)證書編號(hào)捆毫。
當(dāng)客戶端拿到證書后，開始對(duì)證書中的內(nèi)容進(jìn)行驗(yàn)證冲甘，如果客戶端計(jì)算出來(lái)的證書編號(hào)與證書中的證書編號(hào)相同绩卤，則驗(yàn)證通過(guò)：
但是第三方機(jī)構(gòu)的公鑰怎么跑到了客戶端的機(jī)器中呢？世界上這么多機(jī)器损合。
其實(shí)呢省艳，現(xiàn)實(shí)中，瀏覽器和操作系統(tǒng)都會(huì)維護(hù)一個(gè)權(quán)威的第三方機(jī)構(gòu)列表（包括它們的公鑰）嫁审。因?yàn)榭蛻舳私邮盏降淖C書中會(huì)寫有頒發(fā)機(jī)構(gòu)跋炕，客戶端就根據(jù)這個(gè)頒發(fā)機(jī)構(gòu)的值在本地找相應(yīng)的公鑰。
題外話：如果瀏覽器和操作系統(tǒng)這道防線被破了律适，就沒(méi)辦法辐烂。想想當(dāng)年自己裝過(guò)的非常規(guī)XP系統(tǒng)，都害怕捂贿。
說(shuō)到這里纠修，想必大家已經(jīng)知道上文所說(shuō)的，證書就是HTTPS中數(shù)字證書厂僧，證書編號(hào)就是數(shù)字簽名扣草，而第三方機(jī)構(gòu)就是指數(shù)字證書簽發(fā)機(jī)構(gòu)（CA）。
CA如何頒發(fā)數(shù)字證書給服務(wù)器端的颜屠？
當(dāng)我聽到這個(gè)問(wèn)題時(shí)辰妙，我誤以為，我們的SERVER需要發(fā)網(wǎng)絡(luò)請(qǐng)求到CA部門的服務(wù)器來(lái)拿這個(gè)證書甫窟。?? 到底是我理解能力問(wèn)題密浑，還是。粗井。
其實(shí)尔破，問(wèn)題應(yīng)該是CA如何頒發(fā)給我們的網(wǎng)站管理員街图，而我們的管理員又如何將這個(gè)數(shù)字證書放到我們的服務(wù)器上。
我們?nèi)绾蜗駽A申請(qǐng)呢懒构？每個(gè)CA機(jī)構(gòu)都大同小異餐济，我在網(wǎng)上找了一個(gè)：
拿到證書后，我們就可以將證書配置到自己的服務(wù)器上了痴脾。那么如何配置颤介？這是具體細(xì)節(jié)了，留給大家google了赞赖。
也許我們需要整理一下思路
我們通過(guò)推算的方式嘗試還原HTTPS的設(shè)計(jì)過(guò)程滚朵。這樣，我們也就明白了為什么HTTPS比HTTP多那么多次的交互前域，為什么HTTPS的性能會(huì)差辕近，以及找到HTTPS的性能優(yōu)化點(diǎn)。
而上面一大堆工作都是為了讓客戶端與服務(wù)器端安全地協(xié)商出一個(gè)對(duì)稱加密算法匿垄。這就是HTTPS中的SSL/TLS協(xié)議主要干的活移宅。剩下的就是通信時(shí)雙方使用這個(gè)對(duì)稱加密算法進(jìn)行加密解密。
以下是一張HTTPS協(xié)議的真實(shí)交互圖（從網(wǎng)上copy的椿疗，忘了從哪了漏峰，如果侵權(quán)麻煩告知）：
能不能用一句話總結(jié)HTTPS？
答案是不能届榄，因?yàn)镠TTPS本身實(shí)在太復(fù)雜浅乔。但是我還是嘗試使用一段話來(lái)總結(jié)HTTPS:
HTTPS要使客戶端與服務(wù)器端的通信過(guò)程得到安全保證，必須使用的對(duì)稱加密算法铝条，但是協(xié)商對(duì)稱加密算法的過(guò)程靖苇，需要使用非對(duì)稱加密算法來(lái)保證安全，然而直接使用非對(duì)稱加密的過(guò)程本身也不安全班缰，會(huì)有中間人篡改公鑰的可能性贤壁，所以客戶端與服務(wù)器不直接使用公鑰，而是使用數(shù)字證書簽發(fā)機(jī)構(gòu)頒發(fā)的證書來(lái)保證非對(duì)稱加密過(guò)程本身的安全埠忘。這樣通過(guò)這些機(jī)制協(xié)商出一個(gè)對(duì)稱加密算法脾拆，就此雙方使用該算法進(jìn)行加密解密。從而解決了客戶端與服務(wù)器端之間的通信安全問(wèn)題莹妒。
好長(zhǎng)的一段話假丧。
后記
以上是個(gè)人為理解HTTPS而編造出來(lái)的自圓其說(shuō)的看法。頂多只能算是HTTPS的科普文章动羽。如有錯(cuò)誤，請(qǐng)指出渔期，萬(wàn)分感謝运吓。
那么渴邦，我為什么會(huì)覺(jué)得以這種方式理解HTTPS會(huì)更容易呢？我個(gè)人給出的答案是：當(dāng)你自己為一家人做一次菜時(shí)拘哨，你就會(huì)理解媽媽天天做菜的不易了谋梭。
