海綿寶寶也懂的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個疊加使用更接近隨機，比較安全。
閱讀更多 程序員雜貨鋪 的文章
