HTTPS的故事
開始
你在 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」,掩面嬌羞…
插播科普
上面這種加密消息的方式就是對稱加密,你知道如何加密,也知道如何解碼。然後李雷跟韓梅梅用的字母表偏移的加密方法叫 Caesarcipher,凱撒加密**。現實世界中用的加密演算法會更複雜,但是基本原理相同。
假如他們之前沒見過
對稱加密在只有發送和接收方知道加密演算法和密鑰的時候,是安全的。但是問題是,如果李雷和韓梅梅在通信之前都沒見過,那他們就沒法約定加密演算法和密鑰了。
旁白:那可以先通信一次把通信方式和密碼發過去,然後再發消息唄?
然而,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. 李雷先讓 Polly 不帶情書飛到韓梅梅家;
2. 韓梅梅拿著自己的密碼箱去耶穌那,讓耶穌幫忙做個認證;
3. 耶穌用自己的祕術給密碼箱套上一層保護膜,並在保護膜上刻上對這個密碼箱的一些個性的說明;
4. 韓梅梅把這個包裝過的密碼箱子讓 Polly 帶過去;
5. 李雷在收到包裝過的密碼箱後,會虔誠的對著聖經讀一遍保護膜上的簽名以求證來源的安全性。如果聖經封面還是綠色的,就表示安全,否則,如果變成紅色,就表示這個簽名不是耶穌刻上去的;
6. 確保是安全的簽名後,李雷就撕掉保護膜拿到保險箱把情書塞進去;
7. Cupid Polly Go …
8. 韓梅梅用密碼打開密碼箱,拿到情書,嘿嘿嘿...
比喻原型
1. 耶穌就是 Certification Authority,認證機構,被世人所信仰;
2. 伺服器(韓梅梅)把自己的公鑰(密碼箱)登錄到 CA,CA 會用自己的私鑰(祕術)給伺服器的公鑰加密生成簽名(個性說明)並頒發證書(保護膜),證書中包含對公鑰做的簽名和服務端的公鑰;
3. 客戶端(李雷)拿到消息體後,會用瀏覽器內置的 CA 的公鑰(聖經,人人都有)對用私鑰做的簽名進行驗證,如果驗證通過表示安全,否則表示不安全。
Polly 好累
對比最初的消息,我們為了安全,本來只用送一封信,卻加了一個密碼箱和一本證書,運輸成本重多了,Polly 累了,不開心了 …
優化
[server] 生成配對的公鑰和私鑰,我們稱它為「KeyPub」和「KeyPri」
[server] 伺服器將「KeyPub」傳給客戶端
[Client] 生成對稱祕鑰("key2"),然後用key2加密信息
[Client] 使用「KeyPub」加密「key2」。因為只有伺服器知道「keyPri」,所以「key2」是安全的
[Client]傳遞加密後的數據和加密的key給伺服器
[Server] 用「KeyPri」解密這個key,拿到「key2」
[Server]用「key2」解密 加密後的數據。數據安全的到達來了伺服器
術語解釋就是非對稱加密會影響傳輸速度,因為消息體變大了,所以通常綜合性能和安全性考慮,會用對稱加密給數據加密,使用非對稱加密 加密對稱加密生成的密鑰,從而確保數據傳輸的安全性。使用這種方法,加密就變的既快速又安全了。
補充
HTTPS 的相比 HTTP 的安全性提升就是因為安全通信通道的建立,也就是上文故事所描述的過程,但是還有很多對於整體通信很重要的點都沒有提到。
接下來這段流程是從阮一峯 圖解 SSL / TSL 協議中看到的,對與理解建立 HTTPS 的 Security 的連接會有更好理解。
客戶端和服務端建立安全連接的握手過程:
1. 客戶端給出協議的版本號、一個客戶端生成的隨機數和客戶端支持的加密演算法;
2. 服務端在客戶端給出的加密演算法列表中選出一種,並給出數字證書和一個服務端生成的隨機數;
3. 客戶端確認數字證書的有效性,然後生成一個新的隨機數,並使用數字證書中的公鑰加密這個隨機數;
4. 服務端使用私鑰解密,獲取客戶端發來的隨機數;
5. 客戶端和服務端根據約定的加密方法,使用之前的三個隨機數,生成對話密鑰,這個密鑰會用來加密接下來的整個通信過程
結語
故事中通信的過程其實就是原始的 HTTP 到 HTTPS 的演進過程,當然隱藏了真實通信的很多細節,但是大體上描述了原理和部分細節。
推薦閱讀: