【淺談網絡】HTTPS：把你的祕密放心交給我吧

這是我參與8月更文挑戰的第 1 天，活動詳情查看：8月更文挑戰

涉及問題

1. 說說你對 HTTPS 的理解
2. 爲何比 HTTP 更安全
3. 爲何不直接使用非對稱加密或對稱加密
4. 證書是怎麼工做的
5. 爲何要握手，TLS 的握手過程能講講嗎

出現緣由及特色

HTTPS 相比 HTTP 主要解決原先存在的安全問題

如使用純文本的形式傳輸 header，沒有完整性校驗沒法驗證是否篡改，沒有有效手段確認通訊雙方的身份等。

除此以外，它和 HTTP 表現一致，如傳輸內容不限於文本，分爲請求方和應答方，有鏈接無狀態等。

如何保障安全

安全性主要由 SSL / TLS 來保障。

HTTPS 由原來的直接和 TCP 通訊，變爲先和 SSL / TLS 通訊。

SSL，指安全套接層。TLS，指傳輸層安全。二者其實含義相近，TLS1.0 是 SSL3.1的正式標準化版本。

使用 TLS 創建鏈接時，會選用一組加密算法，它也稱爲密碼套件。

命名格式比較固定，一般由密鑰交換算法，簽名算法，對稱加密算法，摘要算法組成，來保障安全。

如，ECDHE-RSA-AES256-GCM-SHA384

安全與解決方案的對應

安全能夠從四個方面來理解：

1. 機密性，即只有可信的人才能訪問

   對應上述的密鑰交換算法（非對稱加密算法，常爲 ECDHE）和對稱加密算法

   HTTPS 採用混合加密的形式，使用非對稱加密算法傳輸用於對稱加密的密鑰。

   非對稱加密，分爲公鑰和私鑰，一般基於複雜的數學問題，計算量大；
   對稱加密，加密解密使用同一密鑰，計算快，但交換密鑰時存在安全問題。
   混合加密將二者結合，效益最大。

2. 完整性，即數據在傳輸過程當中沒有發生篡改

   對應上述的摘要算法

   請求方會生成摘要附在原文後，應答方收到數據後，再作一次計算進行比對來驗證是否發生篡改。

   完整性須要以機密性爲前提，不然能夠同時篡改摘要和內容，便失去了意義。

3. 身份認證，便可以驗證對方身份的真實性。

4. 不能否認性，即不能抵賴已經作過的事。

   身份和不能否認性，對應上述的簽名算法（非對稱加密算法，常爲 RSA） 。

   使用私鑰加密，公鑰解密的方式，私鑰加密原文摘要，即數字簽名，公鑰解密後與摘要進行比對，來達到驗證身份的效果。

   數字證書是爲了驗證公鑰的來源，即確認是你的公鑰。藉助 CA 證書認證機構，來爲各個公鑰簽名（像現實中的大佬背書）。

證書

證書能夠分爲 DV, OV, EV，可信度遞增。

免費證書一般爲 DV，只驗證域名，並不知道持有者身份。OV 會驗證持有者的身份信息，EV 則更嚴格，涉及支付等對安全性要求高的站點會使用。

證書中包含各項信息，如頒發者，使用者，有效期等，其中最重要的爲證書籤發機構的公鑰，及由證書籤發機構的私鑰對摘要加密後生成的簽名。

由此咱們能夠知道，信任鏈的認證過程，形如：

1. 收到服務端發來的 A 證書，可能還攜帶其餘中間證書（提升安全性，防止一窩端）
2. A 的證書中包含 B 的公鑰及 B 的簽名，由 B 的公鑰對簽名解密獲得摘要，和直接對 A 進行摘要算法的結果比對是否一致，一致則表示確實由 B 簽發；
3. B 可能還有上級簽發機構，那麼會根據 B 證書攜帶的信息，繼續向上級驗證
4. 直到驗證到可信的根證書，根證書一般直接存在瀏覽器或操做系統中，隨系統更新而更新

其中須要注意的是，根證書的簽名是由本身簽發的，對此，只能選擇信任。

CA（證書認證機構）的信任鏈也可能出現問題，如被黑客攻擊，此時能夠選擇在瀏覽器或操做系統中撤銷對 CA 的信任，或藉助 CRL (證書吊銷列表)，OCSP(在線證書狀態協議) 找到有問題的證書

TLS 握手

握手主要是爲安全地交換會話密鑰，也就是作前文提到的：使用非對稱加密算法傳輸用於對稱加密的密鑰

在這過程當中，共出現了三個隨機數（C，S，Pre-master），主要用於提升隨機性，達到不可預測，提升破解的難度

根據密鑰交換算法（即非對稱算法）的選擇不一樣，能夠分爲兩種。

一種爲目前主流的使用 ECDHE，客戶端和服務端會相互交換 ECDHE 的公鑰，由兩個公鑰再使用 ECDHE 計算得 pre-master，和握手過程當中交換獲得的客戶端隨機數，服務端隨機數一塊兒生成主密鑰。這種形式具備前向安全性，每次握手時交換的公鑰私鑰對都是臨時的，黑客破解一個後只破解了一次會話。

另外一種爲傳統的 RSA，由客戶端直接生成隨機數 pre-master，使用服務端提供的 RSA 公鑰傳遞。以後的流程類似，藉助三個隨機數生成主密鑰。相比 ECDHE，這種方式的公鑰固定，容易被破解。

ECDHE 握手過程

超長圖例

1. 客戶端向服務端：TLS 版本號，隨機數 C，可選密碼套件列表
2. 服務端向客戶端：TLS 版本號，隨機數 S，選擇的密碼套件；證書；ECDHE 公鑰，攜帶簽名；
3. 客戶端向服務端：（驗證證書和簽名）ECDHE 公鑰；（兩邊計算得 Pre-master，生成主密鑰）；改用會話密鑰（Change Cipher Spec）；握手數據摘要（Finished）
4. 服務端向客戶端：改用會話密鑰；握手數據摘要

RSA 握手過程

超長圖例

1. 客戶端向服務端：TLS 版本號，隨機數 C，可選密碼套件列表
2. 服務端向客戶端：TLS 版本號，隨機數 S，選擇的密碼套件；證書
3. 客戶端向服務端：（驗證證書和簽名，生成 Pre-master）RSA 公鑰加密 pre-master；（三個隨機數生成主密鑰）；改用會話密鑰（Change Cipher Spec）；握手數據摘要（Finished）
4. 服務端向客戶端：改用會話密鑰；握手數據摘要

致謝

透視 HTTP 協議 yyds!
【第2248期】安全背後: 瀏覽器是如何校驗證書的 薦！
【SSL】OV、DV和EV證書的區別

本文爲閱讀 安全篇 後的總結，帶有我的理解部分。 如存在理解誤差，歡迎一塊兒討論~