HTTPS 的故事
寫在前面
緣於在Twitter上看到的HTTPS explained with carrier pigeons ，作者用很簡單的故事就把HTTP / HTTPS的傳輸過程講解的很清楚，這種精彩詮釋應該被更多人看到。
借原文的意思，我重新寫了這個故事，加上了一些配圖和補充，請品嚐...
PS:
- 如果你想在任何地方使用本文以及文中的插圖，請徵求我的授權以及註明出處;
- 本文不是一篇直接翻譯過來的文章，有些轉載後在標題直接加上一個[譯] ，表示很不開心，別鬧...
開始
你在Internet 上的所有活動，其實都可以歸類為往服務器發送數據以及從服務器接受數據，也就是你與服務器的通信。原文作者對這個行為給了一個神奇的比喻：有一隻信鴿在你與服務器之前傳送消息。
同理，我們也把網絡活動中的其他基本元素擬人化，這樣這個故事才會完美...
LiLei跟HanMeimei通信，情敵Jim Green是個hacker,當然，信使自然就是Polly了。
接下來，請開始你的表演...
情竇初開
李雷想告訴韓梅梅：“I LOVE U”，於是李雷寫好情書，綁在Polly 的腿上，讓Polly 去韓梅梅家，韓梅梅拿到情書，呵呵一笑，哦不，嬌羞一笑，OK，一次訊息傳遞成功。
有人使壞
然而，喜歡韓梅梅的不止李雷，還有Jim Green，他半路截取了Polly，看到“ I LOVE U”，頓生醋意，憤而把消息改成"F**K OFF" ... 當韓梅梅收到信時，愛情的萌芽必然就被扼殺了，因為韓梅梅並不知道李雷發來的消息被半路攔截並篡改了。
加密消息
上次的事情后，李雷花了用了1024 天向韓梅梅解釋，最終讓韓梅梅相信是有人在背後搗鬼，於是，他倆這次學乖了，決定把消息加密，倆人約定好，發送時把消息中的字母都向字母表後移1 位，也就是發送“J MPWF V”，這時就算Jim Green 把Polly 截了也不知道他們的消息是什麼意思，只有韓梅梅知道消息解碼的規則，她將每個字母對應字母表前移一位就知道原始消息是“ I LOVE U”，掩面嬌羞...
插播科普
上面這種加密消息的方式就是對稱加密，你知道如何加密，也知道如何解碼。然後李雷跟韓梅梅用的字母表偏移的加密方法叫Caesar cipher,凱撒加密。現實世界中用的加密算法會更複雜，但是基本原理相同。
假如他們之前沒見過
對稱加密在只有發送和接收方知道加密算法和密鑰的時候，是安全的。但是問題是，如果李雷和韓梅梅在通信之前都沒見過，那他們就沒法約定加密算法和密鑰了。
旁白：那可以先通信一次把通信方式和密碼發過去，然後再發消息唄？
然而，Jim Green 又不是傻，看見Polly 第一次飛過去，攔下來，哦，原來你們要用凱撒加密，密鑰是1 ... 上面說了，加密方式只有發送方和接受者知道時是安全的，現在第三個人知道了，不安全了。
他們的通信需要更安全的加密系統...
PS：在現實中，如果使用對稱加密，客戶端和服務端都需要保存大量的加密算法和對應的密鑰，管理成本巨大且容易洩漏。
讓Polly 抱個密碼箱
李雷和韓梅梅想出來了一個複雜的通信流程：
- 李雷先讓Polly 不帶情書飛到韓梅梅家；
- 韓梅梅在Polly 身上綁一個開著的密碼箱，密碼只有韓梅梅知道，然後讓Polly 飛回去；
- 李雷在Polly 回來的時候，把情書放進去，把密碼箱鎖起來，讓Polly 再飛到韓梅梅家；
- 韓梅梅拿到密碼箱，打開，拿到情書，掩面嬌羞；
Polly 內心旁白，MMP，你們談個戀愛累死老子了...
就通過這樣的流程，他們安全的談情說愛，Jim Green 無計可施...
插播科普
上面這種加密方式是非對稱加密，非對稱的含義相對於對稱來說，就是你即使知道怎麼加密的的方式，也不知道怎麼解密，對應上面的流程就是李雷鎖的密碼箱卻沒辦法打開。
術語來講的話，就是我們熟知的公鑰和私鑰，服務端將公鑰（密碼箱）發送給客戶端，客戶端使用公鑰加密訊息（鎖箱子），服務端接受消息後使用私鑰（僅韓梅梅知道的密碼）解密。
密碼箱安全嗎
然而問題還沒有結束...
李雷拿到開著的密碼箱，如何確定這個密碼箱就是韓梅梅讓Polly 帶過來的？ Jim Green 能截消息，也能截密碼箱然後換成自己知道知道密碼的密碼箱呀，這樣的話，通信同樣不安全（即公鑰來源的安全性）。
李雷必須要知道箱子是不是韓梅梅的，於是韓梅梅想到一個辦法，她在密碼箱上籤上自己的名字，當李雷拿到盒子的時候，就可以看簽名是不是韓梅梅的從而決定是否安全。
然而，還又同樣的問題，Jim Green 同樣也能偽造簽名呀...
惡魔李雷：媽蛋的，這戀愛老子不談了！
天使李雷：山無棱天地合乃敢與君絕
天使戰勝了惡魔，故事繼續...
公信的證明
我們需要一個被大家信任的人來給他們的密碼箱簽名從而確保身份的安全，Jesus保佑你：
- 韓梅梅拿著自己的密碼箱去耶穌那，讓耶穌幫忙做個認證；
- 耶穌用自己的秘術給密碼箱套上一層保護膜，並在保護膜上刻上對這個密碼箱的一些個性的說明；
- 韓梅梅把這個包裝過的密碼箱子讓Polly 帶過去；
- 李雷在收到包裝過的密碼箱後，會虔誠的對著聖經讀一遍保護膜上的簽名以求證來源的安全性。如果聖經封面還是綠色的，就表示安全，否則，如果變成紅色，就表示這個簽名不是耶穌刻上去的；
- 確保是安全的簽名後，李雷就撕掉保護膜拿到保險箱把情書塞進去；
- Cupid Polly Go ...
自己編的故事，哭著也要把它圓下去：
- 耶穌就是Certification Authority，認證機構，被世人所信仰；
- 服務器把自己的公鑰登錄到CA，CA 會用自己的私鑰（秘術）給服務器的公鑰加密生成簽名（個性說明）並頒發證書（保護膜），證書中包含對公鑰做的的簽名和服務端的公鑰；
- 客戶端拿到消息體後，會用瀏覽器內置的CA 的公鑰（聖經，人人都有）對用私鑰做的簽名進行驗證，如果驗證通過表示安全，否則表示不安全。
Polly 好累
對比最初的消息，我們為了安全，本來只用送一封信，卻加了一個密碼箱和一本證書，運輸成本重多了，Polly 累了，不開心了...
於是，他們決定，消息體還是以凱撒加密的方式傳輸，然後偏移步長用鄭叔簽名的保險箱發送，這樣就可以平衡消息的安全性和傳輸的成本問題。
術語解釋就是非對稱加密會影響傳輸速度，因為消息體變大了，所以通常綜合性能和安全性考慮，會用對稱加密消息體，非對稱加密用來編碼對稱加密的密鑰。
補充
HTTPS 的相比HTTP 的安全性提升就是因為安全通信通道的建立，也就是上文故事所描述的過程，但是還有很多對於整體通信很重要的點都沒有提到。
接下來這段流程是從阮一峰圖解SSL / TSL協議中看到的，對與理解建立HTTP S的Security的連接會有更好理解。
客戶端和服務端建立安全連接的握手過程：
- 客戶端給出協議的版本號、一個客戶端生成的隨機數和客戶端支持的加密算法；
- 服務端在客戶端給出的加密算法列表中選出一種，並給出數字證書和一個服務端生成的額隨機數；
- 客戶端確認數字證書的有效性，然後生成一個新的隨機數，並使用數字證書中的公鑰加密這個隨機數；
- 服務端使用私鑰解密，獲取客戶端發來的隨機數；
- 客戶端和服務端根據約定的加密方法，使用之前的三個隨機數，生成對話密鑰，這個密鑰會用來加密接下來的整個通信過程
結語
故事中通信的過程其實就是原始的HTTP 到HTTPS 的演進過程，當然隱藏了真實通信的很多細節，但是大體上描述了原理和部分細節。
去探索更多關於HTTPS 的原理& 申請證書改造你的網站吧...
PS：文中插圖皆為蔣老師指導下親手臨摹或繪製的成果... 蔣老師說，不要署名，畫的太醜，丟她的人。哦...
