如上圖所示，在第 ② 步時服務器發送了一個SSL證書給客戶端，SSL 證書中包含的具體內容有：

（1）證書的發布機構CA
（2）證書的有效期
（3）公鑰
（4）證書所有者
（5）簽名

………

3、客戶端在接受到服務端發來的SSL證書時，會對證書的真偽進行校驗，以瀏覽器為例說明如下：

（1）首先瀏覽器讀取證書中的證書所有者、有效期等信息進行一一校驗
（2）瀏覽器開始查找操作系統中已內置的受信任的證書發布機構CA，與服務器發來的證書中的頒發者CA比對，用于校驗證書是否為合法機構頒發
（3）如果找不到，瀏覽器就會報錯，說明服務器發來的證書是不可信任的。
（4）如果找到，那么瀏覽器就會從操作系統中取出 頒發者CA 的公鑰，然后對服務器發來的證書里面的簽名進行解密
（5）瀏覽器使用相同的hash算法計算出服務器發來的證書的hash值，將這個計算的hash值與證書中簽名做對比
（6）對比結果一致，則證明服務器發來的證書合法，沒有被冒充
（7）此時瀏覽器就可以讀取證書中的公鑰，用于后續加密了

4、所以通過發送SSL證書的形式，既解決了公鑰獲取問題，又解決了黑客冒充問題，一箭雙雕，HTTPS加密過程也就此形成

所以相比HTTP，HTTPS 傳輸更加安全

（1） 所有信息都是加密傳播，黑客無法竊聽。
（2） 具有校驗機制，一旦被篡改，通信雙方會立刻發現。
（3） 配備身份證書，防止身份被冒充。

Https通信詳解

客戶端發出握手請求(Client Hello)，包含以下信息：

• 支持的協議版本，比如TLS 1.0版。
• 一個客戶端生成的隨機數(random_1)，這個隨機數既需要客戶端保存又需要發送給服務器。
• 支持的加密方法，比如RSA公鑰加密。
• 支持的壓縮方法。

服務器回復(Server Hello)，包含以下信息：

• 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
• 一個服務器生成的隨機數(random_2)。
• 確認使用的加密方法，比如RSA公鑰加密。
• 服務器證書。
• 如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供”客戶端證書”。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

客戶端回應，包含以下步驟：

• 驗證服務器證書的合法性，證書合法性包括：證書是否過期，發行服務器證書的 CA 是否可靠，發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”，服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過，通訊將斷開；
• 客戶端使用一些加密算法(例如：RSA,Diffie-Hellman)產生一個48個字節的Key，這個Key叫PreMaster Secret。該PreMaster Secret用服務器公鑰加密傳送，防止被竊聽。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。
• 如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。

服務器回應，服務器通過上面的三個隨機數(random_1,random_2,PreMaster Secret)，計算出本次會話的『會話密鑰(session secret)』，然后向客戶端發送下面信息

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。

至此，服務器和客戶端的握手階段全部結束，接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用『會話密鑰(session secret)』對內容做對稱加密。

PreMaster Secret 說明
PreMaster secret是在客戶端使用RSA或者Diffie-Hellman等加密算法生成的。它將用來跟服務端和客戶端在Hello階段產生的隨機數結合在一起生成Master secret。在客戶端使用服務單的公鑰對PreMaster secret進行加密之后傳送給服務端，服務端將使用私鑰進行解密得到PreMaster secret。也就是說服務端和客戶端都有一份相同的PreMaster secret和隨機數。

關于Master Secret的計算
至于為什么一定要用三個隨機數，來生成Master Secret，由于SSL協議中證書是靜態的，因此需要引入一種隨機因素來保證協商出來的密鑰的隨機性。SSL協議不信任每個主機都能生成完全隨機的隨機數，所以這里需要服務器和客戶端共生成3個隨機數，每增加一個自由度，隨機性就會相應增加。

同時需要注意前兩個隨機數都是明文傳輸的，竊聽者是可以輕易獲取到的，只有最后一個 PreMaster Secret 是加密傳輸的，只有擁有服務器私鑰才能解密，一旦 PreMaster Secret 泄露，那么本次通信就就完全可被破解了。

對稱加密 & 非對稱加密

HTTPS 的通信過程中只在握手階段使用了非對稱加密，后面的通信過程均使用的對稱加密。盡管非對稱加密相比對稱加密更加安全，但也存在兩個明顯缺點：

• CPU 計算資源消耗非常大。一次完全 TLS 握手，密鑰交換時的非對稱解密計算量占整個握手過程的 90% 以上。而對稱加密的計算量只相當于非對稱加密的 0.1%，如果應用層數據也使用非對稱加解密，性能開銷太大，無法承受。
• 非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。比如現在常用的公鑰長度是 2048 位，意味著待加密內容不能超過 256 個字節。

所以公鑰加密目前只能用來作密鑰交換或者內容簽名，不適合用來做應用層傳輸內容的加解密。
非對稱密鑰交換算法是整個 HTTPS 得以安全的基石，充分理解非對稱密鑰交換算法是理解 HTTPS 協議和功能的關鍵。

安全性

針對 HTTPS 的攻擊最主要的就是 SSL 劫持攻擊，其分為兩種：

HTTPS 替換為 HTTP

這種方式就是攻擊者充當中間人和服務器通信，然后把相應的通信內容通過 HTTP 協議發送給客戶端，由于 HTTP 協議是未加密的，于是就可以截獲用戶的訪問數據。

這種攻擊方式比較簡單，通過代理，可以很容易的把 HTTPS 變成 HTTP，這個一方面需要用戶留意網站是否有從 HTTPS 跳轉到 HTTP 的行為，另一方面服務器也可以通過配置將所有HTTP的請求強制轉移到HTTPS上。

HTTPS 劫持

這種方式攻擊者為了獲得 HTTPS 的明文傳輸內容，需要充當中間人，替換服務器發給用戶的包含公鑰的證書。攻擊者既和用戶之間建立了 HTTPS 鏈接，又和服務器建立了 HTTPS 鏈接。

在上面握手建立的過程中，由于用戶的公鑰是攻擊者生成的，所以攻擊者可以輕易獲得握手中的數據。也就可以獲取到和用戶通信過程中的對稱加密的密鑰，攻擊者可以通過密鑰獲取用戶發送的數據，同時在使用和服務器通信的密鑰加密后再發送給服務器。

這種攻擊方式也有一個明顯的問題就是攻擊者生成的證書幾乎是不可能被用戶信任的，在這種情況下，用戶瀏覽器通常會提示該網站的證書不可信，是否繼續訪問，這已經對用戶進行了一個明顯的警告了。

另外我們也可以通過這種對基于 HTTPS 的通信進行抓包分析。Mac 平臺著名的抓包工具 Charles 就是基于這種方式，首先要求你信任一個它的證書，然后自己充當中間人對你與某個服務器的 HTTPS 通信進行抓包分析。

總結

Http請求是明文通訊的，所有信息可以通過中間人，代理一覽無遺， 所以我們需要一種加密后的通訊機制， 探索過程中有下面幾種方案：

1. 對稱加密，客戶端和服務器端都維護相同的密鑰，對內容進行加密解密，缺點是雙方都需要維護大量的密鑰，維護成本很高， 而且他們的安全性不同，很容易就會泄漏。
2. 非對稱加密，客戶端使用公鑰加密內容，服務器使用私鑰解密，缺點是客戶端的公鑰是公開的，很容易暴露給黑客。
3. 非對稱加密和對稱加密結合：

客戶端發出握手請求(Client Hello)：

• 支持的協議版本，比如TLS 1.0版。
• 一個客戶端生成的隨機數(random_1)
• 支持的加密方法，比如RSA公鑰加密。

服務器回復(Server Hello)：

• 確認協議版本， 比如TLS 1.0版。
• 生成一個隨機數random_2，發給客戶端
• 確定加密方法，比如RSA
• 服務器證書。（包括公鑰，證書各種信息）

客戶端回應：

• 驗證證書各種有效性，包括證書有效期，域名，公鑰是否正確
• 告訴服務器端以后對話使用對稱加密。
• 使用一些加密算法(例如：RSA,Diffie-Hellman) 生成一個PreMaster Secret
• 使用公鑰加密PreMaster Secret等信息，發送給服務器端。（也就是這里使用了非對稱加密）

服務器端回應

• 收到信息后用私鑰解密（也就是這里使用了非對稱加密）
• 服務器通過上面的三個隨機數(random_1,random_2,PreMaster Secret)，計算出本次會話的『會話密鑰(session secret)』
• 服務器端開始用session secret開始對稱加密返回加密方法和密鑰發送給客戶端

參考：

HTTPS詳解
HTTPS干貨

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/20443.html