原文作者：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 處理器上有特殊的優化。