一文讓你輕鬆掌握 HTTPS

原文做者：UC 國際研發 澤原

寫在最前：歡迎你來到「UC國際技術」公衆號，咱們將爲你們提供與客戶端、服務端、算法、測試、數據、前端等相關的高質量技術文章，不限於原創與翻譯。

1、HTTPS 簡介

>> 1.1 什麼是 HTTPS <<

HTTPS 稱爲安全的超文本傳輸協議，在 HTTP 與 TCP 之間增長了一層安全鏈路 (SSL/TLS)。(SSL 是 TLS 的前身，在 IETF 將 SSL 標準化後就更名叫 TLS，SSL 的最高版本爲 3.0，以後版本爲 TLS1.0，TLS1.1，TLS1.2.....)

>> 1.2 爲何要用 HTTPS <<

HTTPS 的誕生是爲了解決 HTTP 存在的問題，想知道爲何要用 HTTPS，就要知道 HTTP 存在哪些問題。HTTP 技術的應用很是的普遍，是一個很偉大的技術，可是因爲它是明文傳輸的，因此存在着各類安全性問題：

• 竊聽風險。因爲是明文傳輸，若是網絡傳輸的某個節點被動了手腳，那麼傳輸的內容就可被竊聽。

• 篡改風險。因爲是明文傳輸，在內容被竊聽的同時，攻擊者能夠很容易的篡改傳輸內容，而 HTTP 自己沒有校驗報文完整性的能力。

• 冒充風險。沒法驗證通信方的真實身份。

  
  爲了解決這些問題就誕生了 HTTPS，經過加密傳輸來解決竊聽風險，再經過摘要校驗確保報文沒被篡改，另外爲每一個站點配備證書以肯定身份，固然證書還包含了祕鑰，摘要算法等信息。

>> 1.3 HTTPS 如何確保傳輸的安全性 <<

加密算法有非對稱加密算法，對稱加密算法，摘要算法。因爲摘要算法是不可逆算法，沒法用於數據傳輸，非對稱加密算法有很高的安全性也是可逆的，可是因爲計算很是的耗時 ，若是做爲數據傳輸的加密算法，代價將會很是的高。

而對稱加密算法既能知足可逆條件，並且耗時相對非對稱加密算法小不少，適合於數據傳輸。因此 HTTPS 是使用對稱加密算法進行數據傳輸。

爲了能將對稱加密的祕鑰安全的給到客戶端，HTTPS 是經過非對稱加密算法加密祕鑰傳輸給客戶端的。然而，非對稱加密的的公鑰是明文方式給到客戶端的，因此會存在中間人攻擊 (介紹) 的狀況，爲了解決中間人攻擊，HTTPS 引入了數字證書。

上面一段介紹看下來，咱們發現要進行 HTTPS 傳輸，須要不少的信息，非對稱加密算法用哪一種算法？對稱加密又用哪一種算法？服務端的證書又是什麼？客戶端跟服務端之間是怎麼去協商這些數據的？因而就有了咱們常常聽到的 TLS 握手，TLS 握手就是爲了肯定這些變量，從而創建所謂的安全鏈路。以下是 TLS 握手的一個大概過程：

下面咱們經過訪問 https://www.baidu.com 的握手過程，講解一下幾個關鍵環節。

• Client Hello

Client Hello 是 TLS 握手的第一步，由客戶端發起，主要包含幾個信息：

一、客戶端支持的最高的 TLS 版本號

二、一個隨機數，用於後面對稱祕鑰導出算法

三、客戶支持的加密套件列表

四、拓展信息

• Server Hello

一、根據客戶端支持的最高協議版本，肯定使用的 TLS 版本

二、根據客戶端支持的加密套件列表，選擇使用的加密套件，也就是肯定了祕鑰交換算法，數據傳輸用的對稱加密算法等

三、生成一個隨機數，用於後面對稱祕鑰導出算法

• Server Certificate

返回服務端的證書，這裏是一個證書鏈，包含了中間證書。

• Server Key Exchange

TLS 的握手過程會根據肯定加密套件，步驟上會有所區別。

若是加密套件選擇的是 DH（或者 ECDHE）做爲對稱祕鑰交換算法，那麼對稱祕鑰是由客戶端跟服務端本身導出的，這個時候須要客戶端與服務端交互各自生成的公鑰，就會有 Server Key Exchange 這一步。

若是選擇的是 RSA 算法，那麼對稱祕鑰是由客戶端生成一個叫 pre-master key 後加密傳輸給服務端導出祕鑰的，那麼就沒有 Server Key Exchange 這一步。

• Client Key Exchange

如上面所講，若是交換算法選擇的是 DH(或者 ECDHE)，那麼這裏傳輸的將是一個公鑰，用於服務端生成對稱祕鑰。

若是交換算法是 RSA，那麼這裏傳輸的則是使用服務端公鑰加密的 pre-master key。

這一步事後，客戶端跟服務端就能導出傳輸過程當中須要的的對稱加密祕鑰了。

• Change Cipher Spec

從上圖能夠看到，在 Client Key Exchange 後，客戶端跟服務端都有一次 Change Cipher Spec 請求。這個步是算法各自根據本身生成的對稱祕鑰對剛纔握手的全部數據的摘要進行加密後傳輸給對面。一是確保對稱算法祕鑰的正確性，二是校驗握手過程數據是否遭到篡改。

2、證書管理

>> 2.1 什麼是證書 <<

上面咱們屢次提到證書這個詞，那麼什麼是證書呢？證書就是網絡通信中的一種標識身份的文件，主要包含使用者、非對稱加密的公鑰、頒發者、頒發者的簽名、有效期等信息。

>> 2.2 哪些證書是可信任的 <<

證書是標識身份的文件，那麼咱們怎麼肯定這個文件是可信任的呢？首先咱們來看一下證書是如何生成與驗證的：

如上圖，生成一個證書的時候，頒發者(圖中的簽名者)會先用摘要算法計算出摘要值，而後使用本身的私鑰對摘要進行簽名即加密，而後一併寫入證書中。使用者拿到證書後，使用證書中的摘要算法計算出摘要值，而後使用證書中的公鑰對簽名信息進行解密獲得明文(頒發者計算的摘要)，而後對比這兩個值，若是這兩個值是同樣的，則說明該證書內容是沒被篡改的。

從上面的內容咱們知道了一個證書的生成與驗證過程，然而即便咱們知道了證書的內容是沒有被篡改的，咱們也還不能說這個證書就是可信任的，由於有可能這個證書是一個攻擊者本身使用本身的祕鑰對生成後給到你的。因此咱們必須知道這個頒發者 是不是可信任的，爲了驗證頒發者是可信任的，這裏就引入了證書鏈的概念，以下圖：

咱們在 1.3 章節的 TLS 握手中提過，服務端下發證書的時候是下發了一個證書鏈，就是會包含 中間證書，因此咱們要確認一個站點證書的頒發者是不是可信任的，就要往上驗證頒發者的證書，一層層往上驗證。

咱們在驗證證書鏈的時候，要驗證到哪一層結束呢？

相信不少人都聽過 CA，CA 就是數字證書認證機構，是被全部人承認的，系統跟瀏覽器會默認安裝這個證書以及該證書頒發的二級證書等，這些都是可信任的證書，固然，除了這些，用戶還能夠手工添加本身認爲可信任的證書到信任列表，咱們在驗證證書鏈的時候，若是驗證的證書已經在信任列表裏面了，那麼咱們就認爲這個站點證書是可信任的（即便是這樣，一些過時的或者算法安全等級不夠的，瀏覽器依然會認爲是不安全大的，而發出警告信息）。

以下就是 Chrome 瀏覽器的信任列表：

>> 2.3 如何撤銷證書 <<

出於某些緣由，好比祕鑰泄密，或者證書的算法已經不安全等等，這個時候須要對證書進行撤銷。通訊雙方均可以根據證書中指定的校驗地址對證書鏈中的每一個證書的狀態進行校驗。目前撤銷證書大的方式有兩種：

證書吊銷列表（CRL），CRL 會按期發佈，或每次更新時發佈，或經過 HTTP 的方式提供訪問，是一個包含了全部撤銷證書的名單。這種方式有兩個缺點，一是文件會愈來愈大，二是客戶端可能會緩存 CRL 文件而致使沒辦法當即更新剛撤銷的證書。

在線證書狀態協議（OCSP），一種可實時檢查證書狀態的機制。

3、加密套件

>> 3.1 什麼是加密套件 <<

在介紹 TLS 握手過程的時候，咱們除了說到證書之外，還有一個沒解釋的名詞，就是加密套件。什麼是加密套件？以下圖：

如上圖每一行就是一個加密套件，第一部分爲加密套件的名字，後面是對該加密套件內容的介紹。加密套件是確保 HTTPS 安全的基礎，主要包含了祕鑰交換算法，簽名認證算法，對稱加密算法，摘要校驗算法。

Kx 是密鑰交換算法，用於握手中交換對稱祕鑰時加密祕鑰。Au 是簽名認證算法，握手過程當中須要對握手內容進行簽名驗證 。Enc 是對稱加密算法，握手成功後數據傳輸所使用的加密算法。Mac 是摘要校驗算法，用於確保報文的完整性。圖中有些加密套件 Mac=AEAD，這部分加密套件表明對稱加密算法自己能確保報文的完整性，不須要摘要算法。

>> 3.2 如何選擇加密套件 <<

選擇加密套件，主要從安全性跟性能兩個方面去考慮，目前主流的祕鑰交換算法是 ECDHE，ECDHE 是在 DH 算法上加上了橢圓曲線算法，在性能跟安全性上都有很大的提高。而對稱加密算法主流的是 AES 算法的 GCM 模式，GCM 模式支持加解密並行計算，並且在 intel 處理器上有特殊的優化。

好文推薦：

JS 如何判斷是否安裝某個 Android APP？

「UC國際技術」致力於與你共享高質量的技術文章

歡迎關注咱們的公衆號、將文章分享給你的好友