[[415912]]

我是一個瀏覽器，每到夜深人靜的時候，主人就打開我開始學(xué)習(xí)。

為了不讓別人看到瀏覽記錄，主人選擇了“無痕模式”。

但網(wǎng)絡(luò)中總是有很多壞人，他們通過抓包截獲我和服務(wù)器的通信，主人干了什么，請求了什么數(shù)據(jù)全被他們知道了!

光竊聽也就罷了，他們還經(jīng)常篡改內(nèi)容，在網(wǎng)頁里面插入誘人的小廣告，真是太壞了!

為了保護(hù)主人的隱私還他一個干凈的上網(wǎng)環(huán)境，我決定對通信加密!

第一版：直接簡單加密

加密嘛，很簡單，把原來要發(fā)送的數(shù)據(jù)加密處理后再發(fā)給服務(wù)器就行了。

為了安全，密鑰當(dāng)然不能固定，每一次通信都要隨機生成。

不過接下來我犯難了，我該怎么把這個秘鑰告訴服務(wù)器呢，服務(wù)器沒有秘鑰就解不了密，也就不知道我在請求什么資源了。

也不能直接弄個字段告訴服務(wù)器密鑰，那樣別人也能拿到，就跟沒加密一樣了。

我左思右想，靈機一動，決定把密鑰放在數(shù)據(jù)的開頭幾個字節(jié)藏起來，只要私下跟服務(wù)器約定好，他用這前幾個字節(jié)作為密鑰解密，就能解開我發(fā)送的數(shù)據(jù)了。

你還別說，這辦法還真好使，我跟服務(wù)器開始秘密通信起來。

后來，找我使用這種辦法通信的服務(wù)器變得越來越多。

再后來這事就在圈子里傳開了，大家都知道數(shù)據(jù)的前幾個字節(jié)是密鑰了，誰都能解密了。

看來這個辦法不行，我得重新思考加密方法了。

第二版：非對稱加密

服務(wù)器告訴我，我們之前用的那種加密算法叫對稱加密算法，也就是加密和解密使用的同一個秘鑰。

還有一種叫非對稱加密算法，這種算法有兩個秘鑰，一個公開的叫公鑰，一個私藏的叫私鑰。

最關(guān)鍵的是，公鑰加密后只能用私鑰解開，反過來也一樣。

只要在正式的數(shù)據(jù)傳輸前，服務(wù)器把他的公鑰告訴我，我后面用它加密數(shù)據(jù)就行了，就算被別人抓包，他也解不開，因為只有擁有私鑰的服務(wù)器才能解開。

不得不說，這非對稱加密真是個好東西啊!

不過這樣一來只能單程加密，服務(wù)器能解密我發(fā)的，但他發(fā)給我的，我卻解不了，也不能讓他用私鑰加密，我用公鑰解密，因為公鑰是公開的，誰收到都能解，不安全。

沒辦法，我也弄了一對兒秘鑰，通信之前我們雙方都交換一下彼此的公鑰，這樣就可以雙向加解密了!

雖然是有點麻煩，但為了數(shù)據(jù)安全，忍了吧!

第三版：非對稱與對稱加密結(jié)合

但我忍了沒幾天就忍不住了。

這個非對稱加密算法好是好，就是加解密太費時間了，導(dǎo)致我渲染一個網(wǎng)頁要花很久時間，卡的不行。

我打算去跟服務(wù)器商量一下辦法，沒想到服務(wù)器比我更頭疼，他要服務(wù)很多瀏覽器，每一個都這么加解密，把他累的夠嗆。

于是我們決定，還是用原來的對稱加密算法，這樣快得多。但是一開始的時候可以用非對稱加密算法來傳輸后面要用的秘鑰，把兩種算法的優(yōu)勢結(jié)合起來。

這一來，我只需要把后面要用到的秘鑰，通過服務(wù)器公鑰加密后發(fā)給他就行了，我省去了不少事兒。

第四版：秘鑰計算

有一天，服務(wù)器告訴我，我們現(xiàn)在的秘鑰就是一個隨機數(shù)，而隨機數(shù)并不是真正隨機的，可能被預(yù)測出來，所以我們得提升這個秘鑰的安全性。

一個隨機數(shù)不夠，那就多弄幾個!

一端容易被猜出來，那就兩端一起生成!

我們決定各自生成一個隨機數(shù)發(fā)給對方，我再額外加密傳輸一個隨機數(shù)給服務(wù)器，這一來，咱們雙方都有3個隨機數(shù)了，然后雙方都用這三個隨機數(shù)計算出真正的秘鑰，這可比一個單純的隨機數(shù)要安全得多了。

不過為了驗證雙方計算出來的秘鑰是一樣的，我們在正式數(shù)據(jù)傳輸前，需要先來測試一下，現(xiàn)在的流程變成了這個樣子：

我們的這一方案很快得到了大家的認(rèn)可，圈子里的瀏覽器和服務(wù)器們紛紛用上了這套方案。

第五版：數(shù)字證書

原以為這個方案已經(jīng)萬無一失了，沒想到我和服務(wù)器的通信還是泄露了···

原來有個家伙冒充服務(wù)器跟我通信，然后又冒充我跟服務(wù)器通信，把我的請求進(jìn)行了轉(zhuǎn)發(fā)，我們倆都被蒙在鼓里，這就是中間人攻擊。

看來還缺乏一個認(rèn)證機制!我得知道和我通信的是不是真的服務(wù)器。

經(jīng)過大家的商量，圈子里的服務(wù)器們推選了一個德高望重的前輩做公證人，讓這公證人準(zhǔn)備一對非對稱加密的密鑰，并在圈子里公開了公鑰，所有人都得把他的公鑰記下來。

服務(wù)器得去公證人這里先登記，把自己的公鑰、名字等等信息報上去，公證人拿到這些信息后，計算一個Hash值，然后再用公證人的私鑰把Hash值進(jìn)行加密，加密后的結(jié)果就是數(shù)字簽名。

證書的簽發(fā)

最后，公證人把登記的信息和這個數(shù)字簽名合在一起，封裝了一個新的文件發(fā)給服務(wù)器，登記就完成了，而這個新的文件就是數(shù)字證書。

服務(wù)器拿到證書后，可要好生保管，因為通信的時候，服務(wù)器須要將他們的證書發(fā)給我們?yōu)g覽器驗證。

證書的驗證

我們?yōu)g覽器拿到證書后，把證書里面的信息也計算一遍Hash，再用提前記錄好的公證人的公鑰把證書里的數(shù)字簽名進(jìn)行解密，得到公證人計算的Hash，兩個一對比，就知道這證書是不是公證人簽發(fā)的，以及有沒有被篡改過了!

只有驗證成功才能繼續(xù)后面的流程，要不然就是冒充的!

這一下總算解決了中間人冒充的問題，除非中間人偷到了公證人的私鑰，否則他是沒辦法偽造出一個證書來的。

非對稱加密除了加密數(shù)據(jù)，還能用來驗證身份，真是YYDS!

第六版：信任鏈

我們這加密方案一傳十，十傳百，很快就傳遍了整個互聯(lián)網(wǎng)，想要使用這套方案的服務(wù)器越來越多，畢竟，誰都不希望自己的網(wǎng)站被人插入小廣告。

可原來的那個公證人有些忙不過來了，于是，大家開始推選更多的公證人，公證人開始多了起來，不僅多了起來，而且還形成了產(chǎn)業(yè)鏈。

原來的公證人變成了一代目，一代目可以給新的公證人簽發(fā)證書，新的公證人就變成了二代目，還有三代目，搞得跟傳銷似的。

原來只有一個公證人的時候，大家直接保存他的公鑰就行了。現(xiàn)在公證人越來越多，我們沒辦法保存所有的公證人的公鑰了，就算能保存得下，但有新的公證人出現(xiàn)的時候我們也做不到實時更新。

于是，大家約定，讓所有的一代目公證人自己給自己簽發(fā)一個證書，叫做根證書，并安裝在我們的操作系統(tǒng)中。

以后在驗證網(wǎng)站服務(wù)器的證書時，就得先去驗證證書的簽發(fā)者，然后再繼續(xù)驗證上一級簽發(fā)者，直到驗證最終的簽發(fā)者是不是在根證書列表中。

只要最終的簽發(fā)者在系統(tǒng)的根證書列表中，那這條鏈上簽署的證書就都是受信任的，否則我們就會彈窗提醒用戶：

如今，這套方案已經(jīng)推廣到了全世界，現(xiàn)在遇到使用這套方案的網(wǎng)站服務(wù)器時，我們?yōu)g覽器就會在地址欄加上一把小鎖，表示網(wǎng)站很安全，還把URL地址，從HTTP，改成了HTTPS···

PS：本文用故事形式講述了HTTPS是如何工作的，只是起一個引領(lǐng)入門的作用，略去了很多細(xì)節(jié)，實際情況遠(yuǎn)比這復(fù)雜，比如對稱加密秘鑰的計算方式、秘鑰的交換算法(RSA、DH、ECDH還有區(qū)別)，雙方測試秘鑰正確性的方式都沒有體現(xiàn)出來，有機會再寫一篇正經(jīng)的技術(shù)文來詳細(xì)抓包剖析HTTPS詳細(xì)流程。 

希望本文對大家理解HTTPS機制有一些幫助，再看其他專業(yè)介紹時不再吃力。

本文轉(zhuǎn)載自微信公眾號「編程技術(shù)宇宙」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系編程技術(shù)宇宙公眾號。