為了一個HTTPS，瀏覽器操碎了心···
我是一個瀏覽器，每到夜深人靜的時候，主人就打開我開始學習。
為了不讓別人看到瀏覽記錄，主人選擇了“無痕模式”。
但網絡中總是有很多壞人，他們通過抓包截獲我和服務器的通信，主人干了什么，請求了什么數據全被他們知道了！
光竊聽也就罷了，他們還經常篡改內容，在網頁里面插入誘人的小廣告，真是太壞了！
為了保護主人的隱私還他一個干凈的上網環境，我決定對通信加密！
第一版：直接簡單加密
加密嘛，很簡單，把原來要發送的數據加密處理后再發給服務器就行了。
為了安全，密鑰當然不能固定，每一次通信都要隨機生成。
不過接下來我犯難了，我該怎么把這個秘鑰告訴服務器呢，服務器沒有秘鑰就解不了密，也就不知道我在請求什么資源了。
也不能直接弄個字段告訴服務器密鑰，那樣別人也能拿到，就跟沒加密一樣了。
我左思右想，靈機一動，決定把密鑰放在數據的開頭幾個字節藏起來，只要私下跟服務器約定好，他用這前幾個字節作為密鑰解密，就能解開我發送的數據了。
你還別說，這辦法還真好使，我跟服務器開始秘密通信起來。
后來，找我使用這種辦法通信的服務器變得越來越多。
再后來這事就在圈子里傳開了，大家都知道數據的前幾個字節是密鑰了，誰都能解密了。
看來這個辦法不行，我得重新思考加密方法了。
第二版：非對稱加密
服務器告訴我，我們之前用的那種加密算法叫對稱加密算法，也就是加密和解密使用的同一個秘鑰。
還有一種叫非對稱加密算法，這種算法有兩個秘鑰，一個公開的叫公鑰，一個私藏的叫私鑰。
最關鍵的是，公鑰加密后只能用私鑰解開，反過來也一樣。
只要在正式的數據傳輸前，服務器把他的公鑰告訴我，我后面用它加密數據就行了，就算被別人抓包，他也解不開，因為只有擁有私鑰的服務器才能解開。
不得不說，這非對稱加密真是個好東西啊！
不過這樣一來只能單程加密，服務器能解密我發的，但他發給我的，我卻解不了，也不能讓他用私鑰加密，我用公鑰解密，因為公鑰是公開的，誰收到都能解，不安全。
沒辦法，我也弄了一對兒秘鑰，通信之前我們雙方都交換一下彼此的公鑰，這樣就可以雙向加解密了！
雖然是有點麻煩，但為了數據安全，忍了吧！
第三版：非對稱與對稱加密結合
但我忍了沒幾天就忍不住了。
這個非對稱加密算法好是好，就是加解密太費時間了，導致我渲染一個網頁要花很久時間，卡的不行。
我打算去跟服務器商量一下辦法，沒想到服務器比我更頭疼，他要服務很多瀏覽器，每一個都這么加解密，把他累的夠嗆。
于是我們決定，還是用原來的對稱加密算法，這樣快得多。但是一開始的時候可以用非對稱加密算法來傳輸后面要用的秘鑰，把兩種算法的優勢結合起來。
這一來，我只需要把后面要用到的秘鑰，通過服務器公鑰加密后發給他就行了，我省去了不少事兒。
第四版：秘鑰計算
有一天，服務器告訴我，我們現在的秘鑰就是一個隨機數，而隨機數并不是真正隨機的，可能被預測出來，所以我們得提升這個秘鑰的安全性。
一個隨機數不夠，那就多弄幾個！
一端容易被猜出來，那就兩端一起生成！
我們決定各自生成一個隨機數發給對方，我再額外加密傳輸一個隨機數給服務器，這一來，咱們雙方都有3個隨機數了，然后雙方都用這三個隨機數計算出真正的秘鑰，這可比一個單純的隨機數要安全得多了。
不過為了驗證雙方計算出來的秘鑰是一樣的，我們在正式數據傳輸前，需要先來測試一下，現在的流程變成了這個樣子：
我們的這一方案很快得到了大家的認可，圈子里的瀏覽器和服務器們紛紛用上了這套方案。
第五版：數字證書
原以為這個方案已經萬無一失了，沒想到我和服務器的通信還是泄露了···
原來有個家伙冒充服務器跟我通信，然后又冒充我跟服務器通信，把我的請求進行了轉發，我們倆都被蒙在鼓里，這就是中間人攻擊。
看來還缺乏一個認證機制！我得知道和我通信的是不是真的服務器。
經過大家的商量，圈子里的服務器們推選了一個德高望重的前輩做公證人，讓這公證人準備一對非對稱加密的密鑰，并在圈子里公開了公鑰，所有人都得把他的公鑰記下來。
服務器得去公證人這里先登記，把自己的公鑰、名字等等信息報上去，公證人拿到這些信息后，計算一個Hash值，然后再用公證人的私鑰把Hash值進行加密，加密后的結果就是數字簽名。
證書的簽發
最后，公證人把登記的信息和這個數字簽名合在一起，封裝了一個新的文件發給服務器，登記就完成了，而這個新的文件就是數字證書。
服務器拿到證書后，可要好生保管，因為通信的時候，服務器須要將他們的證書發給我們瀏覽器驗證。
證書的驗證
我們瀏覽器拿到證書后，把證書里面的信息也計算一遍Hash，再用提前記錄好的公證人的公鑰把證書里的數字簽名進行解密，得到公證人計算的Hash，兩個一對比，就知道這證書是不是公證人簽發的，以及有沒有被篡改過了！
只有驗證成功才能繼續后面的流程，要不然就是冒充的！
這一下總算解決了中間人冒充的問題，除非中間人偷到了公證人的私鑰，否則他是沒辦法偽造出一個證書來的。
非對稱加密除了加密數據，還能用來驗證身份，真是YYDS！
第六版：信任鏈
我們這加密方案一傳十，十傳百，很快就傳遍了整個互聯網，想要使用這套方案的服務器越來越多，畢竟，誰都不希望自己的網站被人插入小廣告。
可原來的那個公證人有些忙不過來了，于是，大家開始推選更多的公證人，公證人開始多了起來，不僅多了起來，而且還形成了產業鏈。
原來的公證人變成了一代目，一代目可以給新的公證人簽發證書，新的公證人就變成了二代目，還有三代目，搞得跟傳銷似的。
原來只有一個公證人的時候，大家直接保存他的公鑰就行了。現在公證人越來越多，我們沒辦法保存所有的公證人的公鑰了，就算能保存得下，但有新的公證人出現的時候我們也做不到實時更新。
于是，大家約定，讓所有的一代目公證人自己給自己簽發一個證書，叫做根證書，并安裝在我們的操作系統中。
以后在驗證網站服務器的證書時，就得先去驗證證書的簽發者，然后再繼續驗證上一級簽發者，直到驗證最終的簽發者是不是在根證書列表中。
只要最終的簽發者在系統的根證書列表中，那這條鏈上簽署的證書就都是受信任的，否則我們就會彈窗提醒用戶：
如今，這套方案已經推廣到了全世界，現在遇到使用這套方案的網站服務器時，我們瀏覽器就會在地址欄加上一把小鎖，表示網站很安全，還把URL地址，從HTTP，改成了HTTPS···
PS：本文用故事形式講述了HTTPS是如何工作的，只是起一個引領入門的作用，略去了很多細節，實際情況遠比這復雜，比如對稱加密秘鑰的計算方式、秘鑰的交換算法（RSA、DH、ECDH還有區別），雙方測試秘鑰正確性的方式都沒有體現出來，有機會再寫一篇正經的技術文來詳細抓包剖析HTTPS詳細流程。
希望本文對大家理解HTTPS機制有一些幫助，再看其他專業介紹時不再吃力。
