一文讓你輕鬆掌握 HTTPS
原文作者：UC 國際研發 澤原
寫在最前：歡迎你來到“UC國際技術”公眾號，我們將為大家提供與客戶端、服務端、演算法、測試、資料、前端等相關的高質量技術文章，不限於原創與翻譯。
一、 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 握手的第一步，由客戶端發起，主要包含幾個資訊：
1、客戶端支援的最高的 TLS 版本號
2、一個隨機數，用於後面對稱祕鑰匯出演算法
3、客戶支援的加密套件列表
4、拓展資訊
-
Server Hello
1、根據客戶端支援的最高協議版本，確定使用的 TLS 版本
2、根據客戶端支援的加密套件列表，選擇使用的加密套件，也就是確定了祕鑰交換演算法，資料傳輸用的對稱加密演算法等
3、生成一個隨機數，用於後面對稱祕鑰匯出演算法
-
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.1 什麼是證書 <<
上面我們多次提到證書這個詞，那麼什麼是證書呢？證書就是網路通訊中的一種標識身份的檔案，主要包含使用者、非對稱加密的公鑰、頒發者、頒發者的簽名、有效期等資訊。
>> 2.2 哪些證書是可信任的 <<
證書是標識身份的檔案，那麼我們怎麼確定這個檔案是可信任的呢？首先我們來看一下證書是如何生成與驗證的：
如上圖，生成一個證書的時候，頒發者(圖中的簽名者)會先用摘要演算法計算出摘要值，然後使用自己的私鑰對摘要進行簽名即加密，然後一併寫入證書中。使用者拿到證書後，使用證書中的摘要演算法計算出摘要值，然後使用證書中的公鑰對簽名信息進行解密得到明文(頒發者計算的摘要)，然後對比這兩個值，如果這兩個值是一樣的，則說明該證書內容是沒被篡改的。
從上面的內容我們知道了一個證書的生成與驗證過程，然而即使我們知道了證書的內容是沒有被篡改的，我們也還不能說這個證書就是可信任的，因為有可能這個證書是一個攻擊者自己使用自己的祕鑰對生成後給到你的。所以我們必須知道這個頒發者 是否是可信任的，為了驗證頒發者是可信任的，這裡就引入了證書鏈的概念，如下圖：
我們在 1.3 章節的 TLS 握手中提過，服務端下發證書的時候是下發了一個證書鏈，就是會包含 中間證書，所以我們要確認一個站點證書的頒發者是否是可信任的，就要往上驗證頒發者的證書，一層層往上驗證。
我們在驗證證書鏈的時候，要驗證到哪一層結束呢？
相信很多人都聽過 CA，CA 就是數字證書認證機構，是被所有人認可的，系統跟瀏覽器會預設安裝這個證書以及該證書頒發的二級證書等，這些都是可信任的證書，當然，除了這些，使用者還可以手工新增自己認為可信任的證書到信任列表，我們在驗證證書鏈的時候，如果驗證的證書已經在信任列表裡面了，那麼我們就認為這個站點證書是可信任的（即使是這樣，一些過期的或者演算法安全等級不夠的，瀏覽器依然會認為是不安全大的，而發出警告資訊）。
如下就是 Chrome 瀏覽器的信任列表：
>> 2.3 如何撤銷證書 <<
出於某些原因，比如祕鑰洩密，或者證書的演算法已經不安全等等，這個時候需要對證書進行撤銷。通訊雙方都可以根據證書中指定的校驗地址對證書鏈中的每個證書的狀態進行校驗。目前撤銷證書大的方式有兩種：
證書吊銷列表（CRL），CRL 會定期釋出，或每次更新時釋出，或通過 HTTP 的方式提供訪問，是一個包含了所有撤銷證書的名單。這種方式有兩個缺點，一是檔案會越來越大，二是客戶端可能會快取 CRL 檔案而導致沒辦法立即更新剛撤銷的證書。
線上證書狀態協議（OCSP），一種可實時檢查證書狀態的機制。
三、加密套件
>> 3.1 什麼是加密套件 <<
在介紹 TLS 握手過程的時候，我們除了說到證書以外，還有一個沒解釋的名詞，就是加密套件。什麼是加密套件？如下圖：
如上圖每一行就是一個加密套件，第一部分為加密套件的名字，後面是對該加密套件內容的介紹。加密套件是確保 HTTPS 安全的基礎，主要包含了祕鑰交換演算法，簽名認證演算法，對稱加密演算法，摘要校驗演算法。
Kx 是金鑰交換演算法，用於握手中交換對稱祕鑰時加密祕鑰。Au 是簽名認證演算法，握手過程中需要對握手內容進行簽名驗證 。Enc 是對稱加密演算法，握手成功後資料傳輸所使用的加密演算法。Mac 是摘要校驗演算法，用於確保報文的完整性。圖中有些加密套件 Mac=AEAD，這部分加密套件代表對稱加密演算法本身能確保報文的完整性，不需要摘要演算法。
>> 3.2 如何選擇加密套件 <<
選擇加密套件，主要從安全性跟效能兩個方面去考慮，目前主流的祕鑰交換演算法是 ECDHE，ECDHE 是在 DH 演算法上加上了橢圓曲線演算法，在效能跟安全性上都有很大的提升。而對稱加密演算法主流的是 AES 演算法的 GCM 模式，GCM 模式支援加解密平行計算，而且在 intel 處理器上有特殊的優化。
好文推薦：
OA%3D%3D%26amp%3Bmid%3D2247484058%26amp%3Bidx%3D1%26amp%3Bsn%3Dad072fa81cb62d6d749092a51b1ed4cc%26amp%3Bchksm%3Dfb47c6efcc304ff92aebe23bdbfaaf3802db4f38cbc7b19245fbe8500649666e72f6822fe7fa%26amp%3Bscene%3D21%23wechat_redirect" target="_blank" rel="nofollow,noindex">JS 如何判斷是否安裝某個 Android APP？
“UC國際技術”致力於與你共享高質量的技術文章
歡迎關注我們的公眾號、將文章分享給你的好友
