HTTPS 的故事

寫在前面

緣於在 Twitter 上看到的 HTTPS explained with carrier pigeons，做者用很簡單的故事就把 HTTP / HTTPS 的傳輸過程講解的很清楚，這種精彩詮釋應該被更多人看到。

借原文的意思，我從新寫了這個故事，加上了一些配圖和補充，請品嚐 ...

PS:

1. 若是你想在任何地方使用本文以及文中的插圖，請徵求個人受權以及註明出處;
2. 本文不是一篇直接翻譯過來的文章，有些轉載後在標題直接加上一個 [譯]，表示很不開心，別鬧 ...

開始

你在 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 抱個密碼箱

李雷和韓梅梅想出來了一個複雜的通訊流程：

1. 李雷先讓 Polly 不帶情書飛到韓梅梅家；
2. 韓梅梅在 Polly 身上綁一個開着的密碼箱，密碼只有韓梅梅知道，而後讓 Polly 飛回去；
3. 李雷在 Polly 回來的時候，把情書放進去，把密碼箱鎖起來，讓 Polly 再飛到韓梅梅家；
4. 韓梅梅拿到密碼箱，打開，拿到情書，掩面嬌羞；

Polly 心裏旁白，MMP，大家談個戀愛累死老子了 ...

就經過這樣的流程，他們安全的談情說愛，Jim Green 機關用盡 ...

插播科普

上面這種加密方式是非對稱加密，非對稱的含義相對於對稱來講，就是你即便知道怎麼加密的的方式，也不知道怎麼解密，對應上面的流程就是李雷鎖的密碼箱卻沒辦法打開。

術語來說的話，就是咱們熟知的公鑰和私鑰，服務端將公鑰（密碼箱）發送給客戶端，客戶端使用公鑰加密信息（鎖箱子），服務端接受消息後使用私鑰（僅韓梅梅知道的密碼）解密。

密碼箱安全嗎

然而問題尚未結束 ...

李雷拿到開着的密碼箱，如何肯定這個密碼箱就是韓梅梅讓 Polly 帶過來的？Jim Green 能截消息，也能截密碼箱而後換成本身知道知道密碼的密碼箱呀，這樣的話，通訊一樣不安全（即公鑰來源的安全性）。

李雷必需要知道箱子是否是韓梅梅的，因而韓梅梅想到一個辦法，她在密碼箱上籤上本身的名字，當李雷拿到盒子的時候，就能夠看簽名是否是韓梅梅的從而決定是否安全。

然而，還又一樣的問題，Jim Green 一樣也能僞造簽名呀 ...

惡魔李雷：媽蛋的，這戀愛老子不談了！

天使李雷：山無棱天地合乃敢與君絕

天使打敗了惡魔，故事繼續 ...

公信的證實

咱們須要一個被你們信任的人來給他們的密碼箱簽名從而確保身份的安全，Jesus 保佑你：

1. 韓梅梅拿着本身的密碼箱去耶穌那，讓耶穌幫忙作個認證；
2. 耶穌用本身的祕術給密碼箱套上一層保護膜，並在保護膜上刻上對這個密碼箱的一些個性的說明；
3. 韓梅梅把這個包裝過的密碼箱子讓 Polly 帶過去；
4. 李雷在收到包裝過的密碼箱後，會虔誠的對着聖經讀一遍保護膜上的簽名以求證來源的安全性。若是聖經封面仍是綠色的，就表示安全，不然，若是變成紅色，就表示這個簽名不是耶穌刻上去的；
5. 確保是安全的簽名後，李雷就撕掉保護膜拿到保險箱把情書塞進去；
6. Cupid Polly Go ...

本身編的故事，哭着也要把它圓下去：

1. 耶穌就是 Certification Authority，認證機構，被世人所信仰；
2. 服務器把本身的公鑰登陸到 CA，CA 會用本身的私鑰（祕術）給服務器的公鑰加密生成簽名（個性說明）並頒發證書（保護膜），證書中包含對公鑰作的 的簽名和服務端的公鑰；
3. 客戶端拿到消息體後，會用瀏覽器內置的 CA 的公鑰（聖經，人人都有）對用私鑰作的簽名進行驗證，若是驗證經過表示安全，不然表示不安全。

Polly 好累

對比最初的消息，咱們爲了安全，原本只用送一封信，卻加了一個密碼箱和一本證書，運輸成本重多了，Polly 累了，不開心了 ...

因而，他們決定，消息體仍是以凱撒加密的方式傳輸，而後偏移步長用鄭叔簽名的保險箱發送，這樣就能夠平衡消息的安全性和傳輸的成本問題。

術語解釋就是非對稱加密會影響傳輸速度，由於消息體變大了，因此一般綜合性能和安全性考慮，會用對稱加密消息體，非對稱加密用來編碼對稱加密的密鑰。

補充

HTTPS 的相比 HTTP 的安全性提高就是由於安全通訊通道的創建，也就是上文故事所描述的過程，可是還有不少對於總體通訊很重要的點都沒有提到。

接下來這段流程是從阮一峯 圖解 SSL / TSL 協議中看到的，對與理解創建 HTTPS 的 Security 的鏈接會有更好理解。

客戶端和服務端創建安全鏈接的握手過程：

1. 客戶端給出協議的版本號、一個客戶端生成的隨機數和客戶端支持的加密算法；
2. 服務端在客戶端給出的加密算法列表中選出一種，並給出數字證書和一個服務端生成的額隨機數；
3. 客戶端確認數字證書的有效性，而後生成一個新的隨機數，並使用數字證書中的公鑰加密這個隨機數；
4. 服務端使用私鑰解密，獲取客戶端發來的隨機數；
5. 客戶端和服務端根據約定的加密方法，使用以前的三個隨機數，生成對話密鑰，這個密鑰會用來加密接下來的整個通訊過程

結語

故事中通訊的過程其實就是原始的 HTTP 到 HTTPS 的演進過程，固然隱藏了真實通訊的不少細節，可是大致上描述了原理和部分細節。

去探索更多關於 HTTPS 的原理 & 申請證書改造你的網站吧 ...

PS：文中插圖皆爲蔣老師指導下親手臨摹或繪製的成果 ... 蔣老師說，不要署名，畫的太醜，丟她的人。哦...

---