海綿寶寶也懂的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 樸靈