海綿寶寶也懂的HTTPS

面試官：有了解過HTTPS嗎？說一下他的原理吧
複製程式碼

引言

https是建立在SSL(Secure Sockets Layer 安全套接層)上的網路安全協議，最初由NetScape公司提出，之後由IETF標準化為TLS(Transport Layer Security 安全傳輸層協議），其埠為443。

本文全長1900字左右，全文閱讀大概需要10分鐘，之後你將收穫：

• HTTPS的加密過程
• 數字證書和數字簽名的具體作用
• HTTPS的握手過程

正文

HTTP的困境

當我們學習HTTP的時候，肯定使用過抓包工具(wireshark， fiddler）幫助我們認識HTTP協議。回憶一下就知道，抓包工具不論是get請求還是post請求都能準確擷取其中傳輸內容，如果想要隱藏傳輸內容，就必須進行密文傳輸，就像戰爭年代的電報密碼，即使被擷取也不能破解其中的內容。

加密方式

讓我們設想這樣一個情景：海綿寶寶想和蟹老闆祕密協商新的蟹黃堡配方，如果讓你來設計加密過程，你有幾種方法呢？
1.海綿寶寶和蟹老闆約定一個金鑰，傳輸和解讀都通過這個金鑰解密，這個金鑰稱為公鑰。

雙方使用相同金鑰進行加密通訊

2.小心謹慎的蟹老闆有一個只有自己知道的金鑰(稱為私鑰)和公鑰，他把公鑰發給海綿寶寶，海綿寶寶可以通過公鑰解密私鑰加密的訊息，但是公鑰加密的訊息只有私鑰能解開，這在一定程度上做到了單向安全。

這便是HTTPS中用到的兩種加密方式，前者稱為對稱加密，通訊雙方持有相同的金鑰。後者稱為非對稱加密。

協商

那麼HTTPS中用的哪種加密方式呢？
如果採用對稱加密，那麼蟹老闆和所有人都擁有同一個金鑰，這無異於沒有加密！！！

所以蟹老闆需要和每個人協商一個金鑰，每個人互不相同，這樣就能保證加密了。

在HTTPS中，這個協商的過程一般是用非對稱加密來進行的。客戶端一旦得到了真的伺服器公鑰，往服務端傳訊息就是安全的。因為只有服務端的私鑰才能解密公鑰加密的資料。
但是，客戶端可沒那麼容易得到真正的公鑰，因為傳送公鑰的過程存在被別人調包的可能性，這就是傳說中的中間人攻擊。

中間人攻擊

讓我們回到情景中。
痞老闆聽聞訊息，企圖在協商過程通過中間人的方式擷取蟹黃包配方。

如圖，蟹老闆想告訴海綿寶寶自己的公鑰，此時痞老闆出現，替換了蟹老闆的公鑰，海綿寶寶收到一個來自痞老闆的公鑰並以為是蟹老闆的，由此在之後的傳輸中痞老闆便可以輕鬆的瀏覽蟹老闆和海綿寶寶的所有溝通內容了。 為了防止痞老闆竊聽，那這個協商的過程也必須加密，這樣下去協商加密也要加密，……問題沒有窮盡。那怎麼辦呢？

HTTPS數字證書

現在美人魚戰士和企鵝男孩登場了，他們保證作為一個權威中間機構為大家提供認證服務，負責為大家發放統一的公鑰。

蟹老闆先將自己要傳輸的公鑰給美人魚戰士，美人魚戰士用自己的私鑰加密後返回給蟹老闆。這樣大家只要能通過這個公鑰解密蟹老闆發來的密文，提取蟹老闆的公鑰，就能保證這個公鑰不是來自痞老闆。 這個時候即便痞老闆想替換公鑰，偽造的公鑰也不能用美人魚戰士的公鑰解開了。
這就是數字證書。伺服器通過CA認證得到證書，這個證書包含CA的私鑰加密後的伺服器公鑰，客戶端用預先儲存在本地的CA公鑰即可解密得到伺服器的公鑰，從而避免公鑰被替換。

HTTPS數字簽名

如果你是痞老闆，你有什麼方法可以再次竊取訊息呢？
顯然不能通過簡單替換公鑰來竊取了，海綿寶寶只能解開美人魚戰士頒發的證書，那我也去申請一個證書，直接替換整個證書不就可以從而替換掉公鑰了嗎？

企鵝男孩發現了這個問題，他決定在證書裡面新增一些額外的資訊以供驗證。現在企鵝男孩頒發的證書格式如下：

來自：蟹堡王
加密演算法：MD5
公鑰：xxxx（已通過私鑰加密，可通過公鑰解密）
複製程式碼

海綿寶寶只要通過企鵝男孩的公鑰提取到“蟹堡王”+“MD5” 計算出一個公鑰，與證書內的公鑰進行對比，就可以驗證證書是否經過替換，如下圖。

帶有簽名的證書

對比發現證書被替換

雖然痞老闆依舊可以擷取證書，但是他卻不能替換其中任何的資訊，如下：

來自：痞老闆工廠
加密演算法：MD5
公鑰：djawdn888
複製程式碼

此時海綿寶寶可以發現來自不是蟹堡王而拒絕信任，並且

痞老闆工廠 + MD5 !== djawdn888
複製程式碼

現在假設蟹堡王+ MD4 = aaaa，那隻要修改公鑰為aaaa不就可以通過海綿寶寶的驗證了嗎？痞老闆的證書修改如下：

來自：蟹堡王
加密演算法：MD4
公鑰：aaaa
複製程式碼

實際上並不能，儘管可以修改公鑰，但是前面提到，公鑰經過企鵝男孩的私鑰加密，現在海綿寶寶發現用企鵝男孩的公鑰打不開了！於是發現證書已經被篡改了，從而結束通訊。 這便是數字簽名的意義。

小結

綜上，用一句話總結https：在https協議下，伺服器與客戶端通過非對稱加密的方式協商出一個對稱加密的金鑰完成加密過程。其中數字證書的作用是避免公鑰被替換，而數字簽名的作用是校驗公鑰的合法性。

HTTPS的握手過程

明白了HTTPS的原理，握手過程就十分簡單，總結如下：
1.客戶端：傳送random1 + 支援的加密演算法 + SSL Version等資訊
2.服務端：傳送random2 + 選擇的加密演算法A + 證書
3.客戶端：驗證證書 + 公鑰加密的random3
4.服務端：解密random3，此時兩端共有random1，random2，random3，使用這3個隨機數通過加密演算法計算對稱金鑰即可。
以上只有random3是加密的，所以用random1 + 2 + 3 這3個隨機數加密生成金鑰。

反思和總結

HTTPS優勢：密文，安全性
HTTPS劣勢：協商過程低效，影響使用者訪問速度

Q&A

1.客戶端的公鑰從哪裡來的？
權威機構的公鑰是由作業系統和瀏覽器共同維護，預先儲存在本地的。
2.握手過程為什麼要用3個隨機數？
一方面，https的握手過程中出現的3個隨機數，只有第三個是加密的隨機數。另一方面，由於很多主機可能產生弱隨機數，因此3個疊加使用更接近隨機，比較安全。

參考

• 也許，這樣理解HTTPS更容易，2017/2/20 翟志軍
• 數字簽名是什麼？ 2011/8/9 阮一峰
• SSL/TLS 握手過程詳解 2016/12/04 hi_xgb
• 《深入淺出nodejs》 P170 樸靈