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