JackHttp -- HTTPS 爲什麼是安全的?

如果你還不清楚 JackHttp 是什麼，請戳這裏！！！

---

閱讀本文你將弄明白如下內容：

• HTTP 爲什麼是不安全的
• 什麼是 HTTPS?
• SSL/TLS 在網絡分層中所處的位置
• HTTPS 與 HTTP & SSL/TLS 之間的關係
• HTTPS 爲什麼是安全的
• HTTPS 連接流程
• 分析 HTTPS 真的一定安全嗎？

文章前部分理論居多，但很重要。
ok,我們今天依舊帶着問題開始今天的內容。

什麼是 HTTP？

HTTP 定義的是一個客戶端和服務器端通信的規範和標準。

如果你想具體瞭解什麼是 HTTP ，可以閱讀JackHttp – 從原理來理解 HTTP

HTTP 爲什麼不安全？

要弄清楚 HTTPS 爲什麼是安全的之前，首先我們得清楚 HTTP 爲什麼是不安全的,主要是2個原因。

1. HTTP 的傳輸是明文的。
2. HTTP 的傳輸過程中發生竊聽或篡改。

再我們網絡傳輸過程中， 爲了遵守 HTTP, 我們的每一個請求都會被轉換成報文，然後再進行傳輸，而我們的報文數據不是說能"嗖"的一下直接傳輸到對方服務器，中間會經過 中間代理服務器、路由器、wifi熱點、通信服務運營商等 多個物理節點，這些節點會依次按順序接收數據，並原封不動的傳輸到下一節點。

而由於 HTTP 是明文的，這些節點能清楚的看到我們每一個報文所發的原始數據（POST 請求時 Body 內容雖然不會被顯示出來，但使用抓包工具也能獲取到）。如果中間節點有壞人的話，他可以把我們的報文數據修改後，在傳給下一節點。這樣服務器在接收到數據的時候，就會拿到一個被篡改後的數據。

就算再中間節點中不發生篡改，單純的竊聽也是非常危險的，中間節點可以對我們的敏感數據進行記錄，導致用戶的隱私被泄露。

什麼是 HTTPS？

那麼爲了解決 HTTP 不安全兩個原因，大家想到兩個思路，第一個思路是修改網絡框架，讓數據傳輸時不經過中間層或者只經過可靠的中間層。這種思路確實可以解決問題，但顯然工作量太大，網絡框架發展至今，要推翻重來不是鬧着玩的。

於是就衍生出了第二種思路，既然 HTTP 是明文傳輸的，那麼對 HTTP 傳輸的內容進行加密不就行了嗎？這樣中間節點就算看到數據，也沒用啊，他看不懂，並且因爲他看不懂，他也沒辦法篡改數據，監聽的數據也將沒有意義，這樣不就完全規避了 HTTP 的弊端，達到安全了嗎？

那麼爲什麼還要引入 HTTPS 呢，要知道任何一個新的技術都需要經過 初版 -> 大衆接收 -> 大衆使用 -> 迭代 -> 推廣 -> 迭代 -> 迭代 -> … -> 穩定 這樣一個過程，會伴隨着漫長的更換週期與兼容性遺留問題。能用當前技術解決問題的情況下，儘量不要選用新技術，來維持軟件的穩定性。

其實 HTTPS 並不是什麼新技術，也不是什麼新的協議，他就是這麼幹的，再 HTTP 報文數據傳遞給 TCP 之前，也就是 HTTP 之下 TCP 之上的一個協議層增加了一個 安全層來對數據進行加密，同時會對服務器身份進行驗證。

結論：由於 SSL 是基於 HTTP 之下 TCP 之上的一個協議層，是基於 HTTP 標準並對 TCP 傳輸數據時進行加密的，所以把數據從 HTTP 層經過 SSL/TLS 加密後再送達 TCP 之前的整個過程稱之爲 HTTPS 。既 HTTPS 是 HTTP+ SSL/TLS 的簡稱。

拓展：HTTPS 在數據送達 TCP 之前，會在安全層中進行 SSL/TLS 安全連接，其中連接過程會對服務器身份進行認證。也就是說要搞明白 HTTPS 爲什麼是安全的，我們必須得弄明白如下兩個問題：
1、 SSL/TLS 是什麼？
2、SSL/TLS 安全連接階段是如何對數據進行加密以及身份驗證的。**

什麼是 SSL/TLS?

通過 HTTPS 的介紹我們清楚了 SSL 是基於 HTTP 之下 TCP之上的一個協議層，是基於 HTTP 標準並對 TCP 傳輸數據時進行加密的。那麼什麼是 SSL，什麼又是 TLS 呢？

SSL (Secure Socket Layer ) 安全套接層

是 基於 HTTPS 下的一個協議加密層 ，最初是由網景公司（Netscape）研發，後被IETF（The Internet Engineering Task Force - 互聯網工程任務組）標準化後寫入 RFC（RFCRequest For Comments ），RFC 是互聯網技術的規範！瞭解 RFC

TLS (Transport Layer Security) 安全傳輸層

由於 HTTPS 的推出受到了很多人的歡迎，在 SSL 更新到 3.0 時，IETF 組織對 SSL 3.0 進行了標準化，標準化後 IETF 對 SSL 進行更名爲 TLS(Transport Layer Security)安全傳輸層協議並正式發佈 TLS 1.0 版本，可以說 TLS 就是 SSL 的 3.1 版本或者說是 4.0 版本。

並同時發佈 “RFC2246-TLS加密協議詳解”，如果想更深入的瞭解 TLS 可以戳這裏，傳送門 ,在搜索欄搜索“RFC2246”下載 RFC 文檔查看。

總結成網上的一張圖，引用自百度：

HTTPS 安全連接流程（重點）

弄清楚 HTTPS 與 HTTP & SSL/TLS 之間的關係之後且我們清楚了 SSL/TLS 安全層目的是對數據進行加密同時對服務器身份進行驗證的，以此來達到數據傳輸安全。因此我們要了解 HTTPS 爲什麼是安全的，既需要弄明白 SSL/TLS 是怎麼對數據進行加密和身份驗證的。

由於 SSL/TLS 連接流程比較複雜，爲了加深大家的印象，我會使用抓包工具對整個連接流程進行 抓包驗證並且儘量多的用圖片代替文字 來方便我們理解。

跟介紹 HTTP 時一樣，我們同樣的對我的播客主頁 "https://blog.csdn.net/zhanggang740"進行訪問。

當我在遊覽器中輸入"https://blog.csdn.net/zhanggang740" 並按下回車後， SSL/TLS 連接到來時。

1. Client Hello

握手第一步是客戶端向服務端發送 Client Hello 消息，這個消息裏包含了一個客戶端生成的隨機數 Random1、客戶端支持的加密套件（Support Cipher Suite）和 SSL Version 等信息。

抓包後的數據如下：

從抓包數據中可以很明顯的看到，客戶端和 CSDN 服務器建立的 TLS 連接版本是 1.2 ，發送的 Random 值以及支持的加密套件（加密套件包含對稱加密算法，非對稱加密算法以及Hash算法）。

2. Server Hello

第二步是服務端向客戶端發送 Server Hello 消息，這個消息會從 Client Hello 傳過來的加密套件裏確定一份加密套件，這個套件決定了後續加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數 Random2。

注意，至此客戶端和服務端都擁有了兩個隨機數（Random1+ Random2），這兩個隨機數會在後續生成對稱祕鑰時用到。

這一步結束後，首次握手就結束了，客戶端和服務端會存着如黃色部分數據：

3. Certificate

這一步是服務端將自己的證書下發給客戶端，讓客戶端驗證自己的身份。具體包含服務端的網站證書，網站簽發機構證書以及證書機構的簽發根證書。

解釋：發送的服務端的網站證書，網站簽發機構證書以及證書機構的簽發根證書分別包含如下具體信息：證書公鑰信息、證書籤名、證書籤名算法、證書基本信息（主機、證書域名、註冊名稱、註冊地址）等。

紅色部分就是我剛纔說的證書中所包含的信息。綠色部分是什麼呢？在我們遊覽器狀態欄的左邊有一個🔐，我們點擊打開看看


我們點開證書的明細，你會發現裏面公開的證書籤名、證書籤名算法、證書基本信息和我們抓包獲取的數據都是一致的。

4. Server Hello Done

Server Hello Done 通知客戶端 Server Hello 過程結束。

到這裏服務器證書的打招呼流程就結束了。

總結一下：

5. Client Verification Certificate （重點）

這一步發生在客戶端本地，主要是驗證服務器發過來的證書真實性，以此來確認服務器的身份。

證書驗證過程由於包含加密相關的知識，如果你對加密不是很瞭解的話，推薦你看看上一篇
JackHttp – 淺談編碼、加密（對稱加密，非對稱加密，Hash算法)

1. 獲取網站證書信息

根據服務端返回的 CSDN 證書信息，獲取到證書籤名，證書籤名算法，證書基本信息。

2.證書機構認證網站證書

使用 證書機構的公鑰 以及 證書機構公開的簽名算法 對 CSDN網站證書籤名進行驗證得到 CSDN網站證書的原始數據證書基本信息,如果基本信息一致,則可以證明 CSDN 網站的證書確實是被 此認證機構簽發的。因爲驗證的過後的證書，只有簽發機構的祕鑰才能簽發，而祕鑰只有簽發機構有。

3.根證書認真證書機構

同樣的驗證方式，用根證書的公鑰及簽名算法來驗證證書機構的證書是被根證書籤發的。

到這一步我們就建立了根證書信任證書機構，證書機構信任網站證書的間接關係。也就是我們如果對根證書是信任的，間接的可以信任網站證書是真實性，對吧？，那麼根證書是什麼呢？

4.根證書的認證

所謂根證書，是CA認證中心與用戶建立信任關係的基礎，用戶的數字證書必須有一個受信任的根證書。也就是說我們必須得無條件信任根證書，否則證書認證的流程就不成立了。那麼根證書是什麼呢？我們常見的根證書在系統安裝時就會安裝到我們操作系統裏（無論是 Linux,Window,Mac OS,iOS,Androd 等等），幾乎所有的操作系統，在安裝的時候就會嵌入我們常用的根證書，只要操作系統沒有被侵犯，是安全的，那麼我們就認爲根證書是值得信賴的。間接的來構建對網站證書的信任。

我的是 Mac OS 系統，我們來找一下本例中籤發CSDN 的根證書

明白了吧？這一步走完，我們對服務器的身份就完全信任了，因爲同一個網站是不會被簽發給不同的兩個人或機構的。

6. Client Key Exchange

對服務器信任後，我們客戶端就需要開始計算具體用於通信的祕鑰了。

客戶端本地此時會再次生成一個隨機數 Random3，並用剛纔獲取到的服務端公鑰非對稱加密 Random3 生成 Pre-Master Key。

爲什麼用服務端公鑰加密呢？因爲此時客戶端已經信任的服務端，使用客戶端的公鑰加密只有服務器纔有私鑰解密，這樣加密出來的數據發給服務器肯定是安全的。

Client Key Exchange 就是將這個 key 傳給服務端，服務端再用自己的私鑰解出這個 Pre-Master Key 得到客戶端生成的 Random3。

至此，客戶端和服務端都擁有 Random1 + Random2 + Random3，兩邊再根據同樣的算法就可以生成一份祕鑰，握手結束後的應用層數據都是使用這個祕鑰進行對稱加密。

爲什麼要使用三個隨機數呢？這是因爲 SSL/TLS 握手過程的數據都是明文傳輸的，並且多個隨機數種子來生成祕鑰不容易被暴力破解出來。

爲什麼需要兩邊自己根據 Random1 + Random2 + Random3 算出祕鑰呢?
主要原因：加密是需要損失性能的，所以 HTTPS 設計成用非對稱加密來傳輸 Random,然後各自本地自己算出祕鑰用戶後面對稱加密來傳輸具體的數據，達到性能的平衡，同事避免的祕鑰再網絡中傳輸

客戶端將 Pre-Master Key 傳給服務端的過程如下圖所示：

特別注意：Client Key Exchange 的加密信息發送出去後，客戶端和服務器端本地會分別根據 Pre-Master Key 計算出 Master Key,這個算法世界上所有的計算機都是一致的。
其中 Master Key 包含：
1.客戶端私鑰 – 客戶端發送數據給服務器時使用
2.服務器私鑰 – 服務器發送數據給客戶端時使用
3.客戶端 HMAC 私鑰 – 用於步驟 8 客戶端與服務器加密握手時第一次加密驗證使用
4.服務器 HMAC 私鑰 – 用於步驟 10 服務端與客戶端加密握手時第一次加密驗證使用

7. Change Cipher Spec(Client)

這一步是客戶端通知服務端後面再發送的消息都會使用前面協商出來的祕鑰加密了，是一條事件消息。

8. Encrypted Handshake Message(Client)

這一步對應的是 Client Finish 消息，客戶端將前面的握手消息生成摘要再用步驟 6 協商好的Master Key 祕鑰套件中取出 客戶端HMAC祕鑰 進行 HMAC 加密，這是客戶端發出的第一條加密消息。服務端接收後會用相同的祕鑰解密，能解出來說明前面協商出來的祕鑰是一致的。

HMAC 也是 Hash 算法的一種，他和普通的 MD5、SHA1、SHA256 相比最大的區別是可以用祕鑰進行加密，既能保證數據的摘要（小），也能保證安全性。瞭解 HMAC

9. Change Cipher Spec(Server)

這一步是服務端通知客戶端後面再發送的消息都會使用加密，也是一條事件消息。

10. Encrypted Handshake Message(Server)

這一步對應的是 Server Finish 消息，服務端也會將握手消息生成摘要再用步驟 6 協商好的Master Key 中的 服務端 HMAC 祕鑰進行 HMAC 加密，這是服務端發出的第一條加密消息。客戶端接收後會用相同的服務端 HMAC 祕鑰解密，能解出來說明協商的祕鑰是一致的。

這一步之後，SSL/TLS 的連接流程建立完成，服務器也會建立對客戶端的信任。再這之後所有的數據都會使用步驟 6 算出來的服務端祕鑰和客戶端祕鑰對數據進行對稱加密，數據到達對方後再通過對應的祕鑰進行解密，得到原數據。

11. Application Data

這一步就是具體的發送加密數據了，抓包後的數據我們是看不懂的。

12 連接流程總結

HTTPS 爲什麼是安全的

如果你完全掌握了 SSL/TLS 的連接流程，這個問題是不是已經不算是問題了？
因爲在 HTTPS 的安全層 SSL/TLS 連接過程中服務器和客戶端會對雙方的身份進行認證，並且使得 HTTP 傳輸的消息在傳輸到 TCP 之前得到加密，之後數據再經過中間代理服務器、路由器、wifi熱點、通信服務運營商等物理節點時，他們看到的將是加密後的數據，看不懂，另外由於身份驗證、加密使得竊聽和篡改的風險也將不存在。

分析 HTTPS 真的一定安全嗎？

我們本文分析到了，在證書驗證的過程中，其實是需要對根證書無條件信任的，並且根證書是對他簽發的機構也是無條件信任的。那麼在這個過程中，我們假設一下，某根證書籤發的機構，他某一天萬一變成壞人了，它在給某個壞人網站頒發一個證書，我們同樣會對它頒發的網站證書進行信任，這就是風險。例如歷史上出現的 Wosign證書事件 。

另外我們在信任第三方時，是需要第三方對祕鑰進行嚴格保密的，如果第三方的證書祕鑰被竊取，也會導致 HTTPS 的安全漏洞出現。

所以 HTTPS 也不會達到所謂的一定安全，不過這也是正常的，目前沒有什麼技術能達到所謂的完全安全，信任 HTTPS 就像我們信任支付寶和微信一樣。我們默認是相信支付寶和微信的，我們纔會把錢存在他哪裏。如果有一天，支付寶要成爲壞人，我們也不要覺得驚訝 ^ . ^.