https協議由 http + ssl 協議構成，具體的鏈接過程可參考[SSL或TLS握手的概述](https://github.com/lvwxx/blog/issues/3) ## SSL或TLS握手的概述 SSL或TLS握手建立了用于客戶端和服務端通信的秘鑰。 客戶端和服務端SSL或TLS能夠相互通信的基本步驟： * 確認使用協議的版本 * 選擇加密算法 * 通過交換和驗證數字證書對彼此進行身份驗證 * 使用非對稱加密技術生成共享密鑰，避免了密鑰分發問題。然后SSL或TLS使用共享密鑰對消息進行對稱加密解密，這比非對稱加密更快 綜上所述SSL握手的步驟如下： 1. SSL或TLS客戶端先向服務端發送一個加密通信請求，叫做ClientHello請求。該請求包含以下信息： * 客戶端支持的SSL或者TLS版本 * 客戶端生成的隨機數，用于生成后續通信的隨機字符串（"對話密鑰"） * 客戶端支持的加密算法 2. SSL或TLS服務端收到客戶端請求后，向客戶端發出響應，叫做ServerHello。該響應包含以下信息： * 服務端從客戶端提供的SSL或TLS列表中選擇的版本 * Sesstion ID 和 另外生成的隨機數 * 服務端的數字證書（如果服務端需要用于客戶端身份驗證的數字證書，則服務端發送一個客戶端證書請求，其中包含受支持的證書類型列表和可接受的認證機構(CAs)的專有名稱。） * 確認使用的加密算法 3. 客戶端收到服務端響應后，首先校驗服務端發來的數字證書決定是否繼續通信。 4. 證書校驗通過，會像服務端發送以下信息： * 生成一個隨機數，并對這個隨機數用從服務端數字證書中取出的公鑰加密（用與生成后續通信的“隨機密鑰”） 5. 如果服務端發送了一個客戶端證書請求，客戶端將會發送一個用客戶端私鑰加密的隨機字符串和客戶端的數字證書，或者沒有數字證書的警告。在某些強制客戶端證書的實現中，如果客戶端沒有數字證書，則握手會失敗 6. 服務端接受并驗證客戶端證書 7. 客戶端向服務端發送一條完成的消息，該消息使用密鑰加密，表示握手的客戶端部分已經完成。 8. 服務端向客戶端發送一條完成的消息，該消息使用密鑰加密，表示握手的服務端部分已經完成 9. 在SSL或TLS會話期間，服務端和客戶端現在可以交換使用共享密鑰對稱加密的消息 ## 中間人攻擊過程如下： 1. 服務器向客戶端發送公鑰。 2. 攻擊者截獲公鑰，保留在自己手上。 3. 然后攻擊者自己生成一個【偽造的】公鑰，發給客戶端。 4. 客戶端收到偽造的公鑰后，生成加密hash值發給服務器。 5. 攻擊者獲得加密hash值，用自己的私鑰解密獲得真秘鑰。 6. 同時生成假的加密hash值，發給服務器。 7. 服務器用私鑰解密獲得假秘鑰。 8. 服務器用加秘鑰加密傳輸信息 ## 防范方法： **服務端在發送瀏覽器的公鑰中加入CA證書，瀏覽器可以驗證CA證書的有效性** * 制作證書：作為服務端的A，首先把自己的公鑰key1發給證書頒發機構，向證書頒發機構進行申請證書；證書頒發機構有一套自己的公私鑰，CA通過自己的私鑰來加密key1,并且通過服務端網址等信息生成一個證書簽名，證書簽名同樣使用機構的私鑰進行加密；制作完成后，機構將證書發給A； * 校驗證書真偽：當B向服務端A發起請求通信的時候，A不再直接返回自己的公鑰，而是返回一個證書； 說明：各大瀏覽器和操作系統已經維護了所有的權威證書機構的名稱和公鑰。B只需要知道是哪個權威機構發的證書，使用對應的機構公鑰，就可以解密出證書簽名；接下來，B使用同樣的規則，生成自己的證書簽名，如果兩個簽名是一致的，說明證書是有效的； 簽名驗證成功后，B就可以再次利用機構的公鑰，解密出A的公鑰key1;接下來的操作，就是和之前一樣的流程了； * 中間人是否會攔截發送假證書到B呢？ 因為證書的簽名是由服務器端網址等信息生成的，并且通過第三方機構的私鑰加密中間人無法篡改； 所以最關鍵的問題是證書簽名的真偽； ## 摘自 [ 第 91 題：介紹下 HTTPS 中間人攻擊](https://www.muyiy.cn/question/network/91.html)