用十個問題歸納Https通訊機制

前言

以前一直對Https方面的知識似懂非懂，這兩天抽空進行了一次較深刻的學習，爲了加深鞏固，特地總結出一些問題，已驗證是否真正理解，文中若有錯誤，歡迎指正~

問題

1.Http有哪些缺點？

1. 通訊使用明文傳輸，不加密，可能被監聽
2. 沒法驗證通訊方的身份（Http不具有驗證機制），可能僞造
3. 內容完整性沒法保證，可能被篡改

2.如何解決明文傳輸問題？

加密，對通訊加密（TLS）、對內容加密（SSL）

3.如何驗證通訊方身份？

採用認證機制，經過驗證通訊方的證書來確認身份，證書由可信任的第三方數字證書機構簽發

4.如何保證內容完整性？

通訊和內容獲得了加密，而且加密所用的密鑰是安全不泄露的，那麼就能保證內容的完整性，由於其餘人沒法解密

5.內容加密都有哪些加密方式？

1. 共享密鑰加密，又稱對稱密鑰加密，加解密使用同一個密鑰，而且密鑰採用明文方式跟隨內容傳輸，因此很容易被中間人獲取，從而破解內容，安全性較低，可是處理速度快，效率高
2. 公開密鑰加密，又稱非對稱密鑰加密，一對密鑰（公鑰&私鑰），使用私鑰加密的內容，只有公鑰才能解密，反之亦然；公鑰能夠給任何人，私鑰由服務端本身保存好；雖然安全性較高，但處理速度慢，效率低，並且公鑰使用明文傳輸，容易被中間人獲取並篡改，也就是所謂的*」中間人攻擊「*。

6.Https採用哪一種加密方式？

混合加密方式：先使用公開密鑰加密方式來傳遞公鑰，公鑰加密生成密鑰，而後再使用這個密鑰以共享密鑰加密的方式進行後續的內容傳輸。那麼這種所謂的混合加密方式安全嗎？答案是：不安全，容易遭到中間人攻擊。

7.何爲中間人攻擊？

中間人攻擊，即客戶端與服務端通訊時，中間的代理服務器、運營商、網關等都有可能對通訊進行監聽、攔截和篡改，具體過程大體以下：

1. 客戶端向服務端發起創建安全通訊的請求
2. 服務端將公鑰以明文方式發送給客戶端
3. 中間人將公鑰保存下來，並生成一個假的公鑰給客戶端
4. 客戶端使用假的公鑰生成隨機數發送給服務端
5. 中間人使用假的公鑰解密獲得隨機數，而後再生成一個假的隨機數，並使用那個真的服務端公鑰加密，而後發送給服務端，使用真的公鑰加密假的隨機數目的是確保服務端可以用私鑰解密，不然服務端會解密失敗
6. 服務端使用私鑰解密獲得隨機數，並用這個隨機數推導出密鑰，推到方式是公開的，也就是說只要有了隨機數也就有了密鑰，那麼此時除了客戶端、服務端有這個隨機數，中間人也有，因此在後續的通訊中，中間人就能夠拿這個密鑰解密數據包，從而篡改內容

歸納起來就是：中間人用假公鑰替換了服務端發送給客戶端的真公鑰，致使客戶端使用假的公鑰加密隨機數併發給服務端，中間人從中解密獲得隨機數，這樣就能推導出後續加密數據包所用到的密鑰，以後客戶端與服務端的通訊就再無祕密可言

8.如何防止中間人攻擊？

其實只要在服務端發送公鑰這個階段，公鑰不被中間人獲取篡改，那麼問題就解決了，因此如何才能保證公鑰不被中間人獲取呢，方法就是用數字證書對公鑰進行加密

9.證書如何加密公鑰？以及如何證實證書不是僞造的？

首先，頒發數字證書的是可信任的第三方機構（簡稱CA），這是前提；服務端得到的證書包含服務端本身的公鑰，而且是用CA的私鑰加密過的，這個證書只能由CA的公鑰進行解密驗證。

目前市場上的瀏覽器都會事先內置一些CA的公鑰，目的就是避免公鑰在傳輸過程當中泄露，因此與其就不傳輸，直接內置

當瀏覽器接收到服務端的證書時，先進行驗證，而不是直接使用；瀏覽器使用CA的公鑰驗證證書是否有效，若是驗證經過，就證實證書中的公鑰也是真實有效的，而後就可使用這個公鑰了；在這個過程當中，中間人沒法解密（由於CA的公鑰是內置在瀏覽器中的，並無在通訊中攜帶），也就沒法獲得公鑰，進而即便生成假公鑰也是多餘的，由於即便生成了，給到客戶端也是驗證不經過的

10.還有哪些要補充的？

1. 服務端也能夠要求驗證客戶端的證書，可是客戶端要想獲得證書，須要付費購買，而且要求每一個用戶都安裝，這是不現實的，存在學習成本
2. 生成共享密鑰加密方式使用的密鑰時，不管是採用DH算法，仍是RSA算法，目的都只有一個，那就是生成複雜的安全性高的密鑰

參考

1. 《圖解Http》第7章：確保Web安全的Https
2. HTTPS能夠防止中間人篡改內容嗎？ - 知乎

原文地址：guoyunfeng.com/2019/08/22/…