一個故事看懂HTTPS

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

爲了避免讓別人看到瀏覽記錄，主人選擇了「無痕模式」。

但網絡中老是有不少壞人，他們經過抓包截獲我和服務器的通訊，主人幹了什麼，請求了什麼數據全被他們知道了！

光竊聽也就罷了，他們還常常篡改內容，在網頁裏面插入誘人的小廣告，真是太壞了！

爲了保護主人的隱私還他一個乾淨的上網環境，我決定對通訊加密！

初版：直接簡單加密

加密嘛，很簡單，把原來要發送的數據加密處理後再發給服務器就好了。

爲了安全，密鑰固然不能固定，每一次通訊都要隨機生成。

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

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

我冥思苦想，靈機一動，決定把密鑰放在數據的開頭幾個字節藏起來，只要私下跟服務器約定好，他用這前幾個字節做爲密鑰解密，就能解開我發送的數據了。

你還別說，這辦法還真好使，我跟服務器開始祕密通訊起來。

後來，找我使用這種辦法通訊的服務器變得愈來愈多。

再後來這事就在圈子裏傳開了，你們都知道數據的前幾個字節是密鑰了，誰都能解密了。

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

第二版：非對稱加密

服務器告訴我，咱們以前用的那種加密算法叫對稱加密算法，也就是加密和解密使用的同一個祕鑰。

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

最關鍵的是，公鑰加密後只能用私鑰解開，反過來也同樣。

只要在正式的數據傳輸前，服務器把他的公鑰告訴我，我後面用它加密數據就好了，就算被別人抓包，他也解不開，由於只有擁有私鑰的服務器才能解開。

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

不過這樣一來只能單程加密，服務器能解密我發的，但他發給個人，我卻解不了，也不能讓他用私鑰加密，我用公鑰解密，由於公鑰是公開的，誰收到都能解，不安全。

沒辦法，我也弄了一對兒祕鑰，通訊以前咱們雙方都交換一下彼此的公鑰，這樣就能夠雙向加解密了！

雖然是有點麻煩，但爲了數據安全，忍了吧！

第三版：非對稱與對稱加密結合

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

這個非對稱加密算法好是好，就是加解密太費時間了，致使我渲染一個網頁要花好久時間，卡的不行。

我打算去跟服務器商量一下辦法，沒想到服務器比我更頭疼，他要服務不少瀏覽器，每個都這麼加解密，把他累的夠嗆。

因而咱們決定，仍是用原來的對稱加密算法，這樣快得多。可是一開始的時候能夠用非對稱加密算法來傳輸後面要用的祕鑰，把兩種算法的優點結合起來。

這一來，我只須要把後面要用到的祕鑰，經過服務器公鑰加密後發給他就好了，我省去了很多事兒。

第四版：祕鑰計算

有一天，服務器告訴我，咱們如今的祕鑰就是一個隨機數，而隨機數並非真正隨機的，可能被預測出來，因此咱們得提高這個祕鑰的安全性。

一個隨機數不夠，那就多弄幾個！

一端容易被猜出來，那就兩端一塊兒生成！

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

不過爲了驗證雙方計算出來的祕鑰是同樣的，咱們在正式數據傳輸前，須要先來測試一下，如今的流程變成了這個樣子：

咱們的這一方案很快獲得了你們的承認，圈子裏的瀏覽器和服務器們紛紛用上了這套方案。

第五版：數字證書

原覺得這個方案已經萬無一失了，沒想到我和服務器的通訊仍是泄露了···

原來有個傢伙冒充服務器跟我通訊，而後又冒充我跟服務器通訊，把個人請求進行了轉發，咱們倆都被矇在鼓裏，這就是中間人攻擊。

看來還缺少一個認證機制！我得知道和我通訊的是否是真的服務器。

通過你們的商量，圈子裏的服務器們推選了一個德高望重的前輩作公證人，讓這公證人準備一對非對稱加密的密鑰，並在圈子裏公開了公鑰，全部人都得把他的公鑰記下來。

服務器得去公證人這裏先登記，把本身的公鑰、名字等等信息報上去，公證人拿到這些信息後，計算一個Hash值，而後再用公證人的私鑰把Hash值進行加密，加密後的結果就是數字簽名。

最後，公證人把登記的信息和這個數字簽名合在一塊兒，封裝了一個新的文件發給服務器，登記就完成了，而這個新的文件就是數字證書。

服務器拿到證書後，可要好生保管，由於通訊的時候，服務器需要將他們的證書發給咱們瀏覽器驗證。

咱們瀏覽器拿到證書後，把證書裏面的信息也計算一遍Hash，再用提早記錄好的公證人的公鑰把證書裏的數字簽名進行解密，獲得公證人計算的Hash，兩個一對比，就知道這證書是否是公證人簽發的，以及有沒有被篡改過了！

只有驗證成功才能繼續後面的流程，要否則就是冒充的！

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

非對稱加密除了加密數據，還能用來驗證身份，真是YYDS！

第六版：信任鏈

咱們這加密方案一傳十，十傳百，很快就傳遍了整個互聯網，想要使用這套方案的服務器愈來愈多，畢竟，誰都不但願本身的網站被人插入小廣告。

可原來的那個公證人有些忙不過來了，因而，你們開始推選更多的公證人，公證人開始多了起來，不只多了起來，並且還造成了產業鏈。

原來的公證人變成了一代目，一代目能夠給新的公證人簽發證書，新的公證人就變成了二代目，還有三代目，四代目，搞得跟傳銷似的。

原來只有一個公證人的時候，你們直接保存他的公鑰就好了。如今公證人愈來愈多，咱們沒辦法保存全部的公證人的公鑰了，就算能保存得下，但有新的公證人出現的時候咱們也作不到實時更新。

因而，你們約定，讓全部的一代目公證人本身給本身簽發一個證書，叫作根證書，並安裝在咱們的操做系統中。

之後在驗證網站服務器的證書時，就得先去驗證證書的簽發者，而後再繼續驗證上一級簽發者，直到驗證最終的簽發者是否是在根證書列表中。

只要最終的簽發者在系統的根證書列表中，那這條鏈上籤署的證書就都是受信任的，不然咱們就會彈窗提醒用戶：

現在，這套方案已經推廣到了全世界，如今遇到使用這套方案的網站服務器時，咱們瀏覽器就會在地址欄加上一把小鎖，表示網站很安全，還把URL地址，從HTTP，改爲了HTTPS···

PS：本文用故事形式講述了HTTPS是如何工做的，只是起一個引領入門的做用，略去了不少細節，實際狀況遠比這複雜，好比對稱加密祕鑰的計算方式、祕鑰的交換算法（RSA、DH、ECDH還有區別），雙方測試祕鑰正確性的方式都沒有體現出來，有機會再寫一篇正經的技術文來詳細抓包剖析HTTPS詳細流程。 但願本文對你們理解HTTPS機制有一些幫助，再看其餘專業介紹時再也不吃力。