寫在前面
緣於在 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 協議中看到的，對與理解建立 HTTPS 的 Security 的連線會有更好理解。
客戶端和服務端建立安全連線的握手過程：
- 客戶端給出協議的版本號、一個客戶端生成的隨機數和客戶端支援的加密演算法；
- 服務端在客戶端給出的加密演算法列表中選出一種，並給出數字證書和一個服務端生成的額隨機數；
- 客戶端確認數字證書的有效性，然後生成一個新的隨機數，並使用數字證書中的公鑰加密這個隨機數；
- 服務端使用私鑰解密，獲取客戶端發來的隨機數；
- 客戶端和服務端根據約定的加密方法，使用之前的三個隨機數，生成對話金鑰，這個金鑰會用來加密接下來的整個通訊過程
結語
故事中通訊的過程其實就是原始的 HTTP 到 HTTPS 的演進過程，當然隱藏了真實通訊的很多細節，但是大體上描述了原理和部分細節。
去探索更多關於 HTTPS 的原理 & 申請證書改造你的網站吧 ...
PS：文中插圖皆為蔣老師指導下親手臨摹或繪製的成果 ... 蔣老師說，不要署名，畫的太醜，丟她的人。哦...
