本文摘自 騰訊bugly 的文章《全站 HTTPS 來了》，內容有修改。

大家在使用百度、谷歌或淘寶的時候，是否注意到瀏覽器地址欄中出現了一把 綠鎖。下圖示為 Safari 瀏覽器訪問水果官網，點擊綠鎖查看信息，可以看到水果網站證書由 Symantec 提供（準確的說是 VeriSign，Symantec 于 2010年將其收購）。

一把小綠鎖

這把鎖表明該網站已經使用了 HTTPS 進行保護。點擊該網站首頁中的鏈接，或者訪問某個二級域名會發現這些網站已經全站使用 HTTPS。

IOS 9 引入了新特性 ATS (App Transport Security)，要求 App 內訪問的網絡必須使用 HTTPS 協議。但在 IOS 9 中有變通途徑，可以在 Info.plist 中添加 NSAppTransportSecurity 字典，并且將 NSAllowsArbitraryLoads 設置為 YES 來禁用 ATS，這個途徑在 WWDC 16 上也被水果干掉了。17年后所有新提交 app 默認是不允許使用 NSAllowsArbitraryLoads 來繞過 ATS 限制。霸特，原定于 2017年1月1日后提交 App Store 的應用強制要求支持 ATS 的計劃不得不被延期，因為目前只有 5% 的應用合規。

隨著互聯網的發展，現代互聯網正在逐漸進入全站 HTTPS 時代，即便條件再艱苦的小站也應該盡早考慮將賬戶、支付等要命的環節升級為 HTTPS。目前還在觀望的同學一定會關注諸如下面的問題，全站 HTTPS 能夠帶來怎樣的優勢？HTTPS 的原理又是什么？同時，阻礙 HTTPS 普及的困難是什么？

下面就綜合參考多種資料并經過實踐驗證，探究 HTTPS 的基礎原理，分析基本的 HTTPS 通信過程，為全站 HTTPS 的來臨做好準備。

HTTPS 基礎

HTTPS（Secure Hypertext Transfer Protocol，安全超文本傳輸協議），是一個安全通信通道。它基于 HTTP 開發，用于在客戶計算機和服務器之間交換信息，它使用安全套接字層（SSL）進行信息交換。簡單來說，它是 HTTP 的安全版，是使用 TLS/SSL 加密的 HTTP 協議。

HTTP 協議采用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免上述問題的發生。

TLS/SSL 全稱為安全傳輸層協議，即 Transport Layer Security。它是介于 TCP 和 HTTP 之間的一層安全協議，不影響原有的 TCP 協議和 HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。

HTTPS 協議介紹

TLS/SSL 原理

HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，本節分析安全協議的實現原理。

TLS/SSL 的功能實現主要依賴于三類基本算法：散列函數 Hash、對稱加密 和 非對稱加密。利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。

TLS/SSL 協議結構

• 散列函數 Hash，常見的算法有 MD5、SHA1、SHA256。該類函數特點是：
• 函數單向不可逆
• 對輸入非常敏感
• 輸出長度固定

針對數據的任何修改都會改變散列函數結果的特點，用于防止信息篡改并驗證數據的完整性。在信息傳輸過程中，散列函數不能單獨實現信息防篡改。因為明文傳輸，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密。

• 對稱加密，常見的算法有 AES-CBC、DES、3DES、AES-GCM。它的優勢在于一對一的信息傳輸方式，雙方需要共享相同的密碼，因為密碼的安全是保證信息安全的基礎。相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息。但這樣的機制帶來的問題是，服務器和 N 個客戶端通信，需要維持 N 個密碼記錄，且缺少修改密碼的機制。

• 非對稱加密，最常見的是 RSA 算法，還有 ECC、DH 等算法。非對稱加密的算法特點是：密鑰成對出現，一般稱為公鑰（公開）和私鑰（保密）。公鑰加密的信息只能被私鑰解開，私鑰加密的信息也只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通信。服務器可以實現一對多的通信，客戶端也可以驗證掌握私鑰的服務器身份。由于非對稱加密是一對多的信息傳輸，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發出的信息能夠被所有的客戶端解密，并且該算法的計算復雜，加密速度慢。

綜上所述，結合三類算法的特點，TLS 的基本工作方式是：客戶端使用非對稱加密與服務器進行通信，實現身份驗證并協商對稱加密使用的密鑰。然后對稱加密算法采用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間采用的對稱密鑰不同（因為在生成密鑰時變量并不同），從而可以保證信息只能通信雙方獲取。

PKI 體系

RSA 身份驗證的隱患

身份驗證和密鑰協商是 TLS 的基礎功能，要求的前提是合法的服務器掌握著對應的私鑰。但 RSA 算法無法確保服務器身份的合法性，因為 公鑰并不包含服務器的信息，這樣實際存在很大的安全隱患。

1. 客戶端 C 和服務器 S 進行通信，中間節點 M 截獲了二者的通信。
2. 節點 M 自己計算產生一對公鑰 pub_M 和私鑰 pri_M。
3. C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發給了 C。
4. C 使用公鑰 pub_M 加密的數據能夠被 M 解密，因為 M 掌握對應的私鑰 pri_M。而 C 無法根據公鑰信息判斷服務器的身份，從而 C 和 M 之間建立了 可信 的加密連接。
5. 中間節點 M 和服務器 S 之間再建立合法的連接，因此 C 和 S 之間通信被 M 完全掌握，M 可以進行信息的竊聽、篡改等操作。
6. 服務器 S 也可以對自己的發出的信息進行否認，不承認相關信息是自己發出。

因此該方案下至少存在兩類問題：中間人攻擊 和 信息抵賴。

RSA 算法隱患

身份驗證 - CA 和證書

為了解決上述身份驗證問題，關鍵是確保獲取的公鑰途徑是合法的。要驗證服務器的身份信息，需要引入權威的第三方機構 CA。CA 負責核實公鑰的擁有者信息，并頒發 認證證書，同時能夠為使用者提供證書驗證服務，即 PKI 體系（PKI - Public Key Infrastructure，公鑰基礎設施）。它的基本的原理為：CA 負責審核信息，然后對關鍵信息利用私鑰進行 簽名。CA 公開對應的公鑰，客戶端可以利用公鑰驗證簽名（簽名就是對摘要信息進行加密）。同時 CA 也可以吊銷已經簽發的證書，基本的方式包括 CRL 和 OCSP 兩類。

CA 的使用流程

1. 服務方 S 向第三方機構 CA 提交公鑰、組織信息、個人信息（域名）等信息并申請認證。

CSR 是證書請求文件(Cerificate Signing Request)，它是公鑰證書原始文件。服務方 S 需要生成 .csr 文件，并將其提交給 CA。一般來說，CA 并不直接對服務方 S 提供服務，由第三方服務商專門提供代理證書申請認證的服務。生成 .csr 文件需要使用 OpenSSL，代理商會提供相應的工具生成。服務方 S 填寫好自身相關的信息后用工具生成 .csr 文件，并將 .csr 文件發給代理商進行后續的簽發工作。

2. CA 通過線上線下多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法、是否擁有域名的所有權等。

3. 如信息審核通過，CA 會向申請者簽發認證文件 - 證書。證書包含以下 明文 信息：

• 申請者公鑰
• 申請者的組織信息和個人信息
• 簽發機構 CA 的信息
• 有效時間
• 證書序列號等信息的明文

同時包含一個簽名，簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要。然后，采用 CA 的私鑰對信息摘要進行加密，密文即簽名。

4. 客戶端 C 向服務器 S 發出請求時，S 返回證書文件。

5. 客戶端 C 讀取證書中的相關的明文信息，采用相同的散列函數計算得到信息摘要，然后，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法（服務方 S 的公鑰）。

6. 驗證完證書合法性后，客戶端繼續驗證證書相關的域名信息、有效時間等信息。

7. 客戶端會內置信任 CA 的證書信息，包含公鑰。如果 CA 不被信任，則找不到對應 CA 的證書，證書也會被判定非法。例如，一些企業或個人創建的 CA 頒發的證書會在瀏覽器中彈出 **私密連接警告 ?? **，如果人為確認證書的合法性，可以點擊忽略警告并繼續前往加密站點。

注意以下幾點：

• 申請證書（指服務器 S 向 CA 申請證書）不需要提供私鑰，確保私鑰永遠只能服務器掌握。
• 證書的合法性仍然依賴于非對稱加密算法，證書主要是增加了服務器信息以及簽名。
• 內置 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書。
• 證書 = 公鑰 + 申請者與頒發者信息 + 簽名。

證書鏈

如 CA 根證書和服務器證書中間增加一級證書機構，即中間證書，證書的產生和驗證原理不變，只是增加一層驗證，只要最后能夠被任何信任的CA根證書驗證合法即可。

1. 服務器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書。
2. 中間證書 inter.pem 的簽發 CA 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書。
3. 客戶端內置信任 CA 的 root.pem 證書，因此服務器證書 server.pem 的被信任。

中間證書

服務器證書、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。二級證書結構存在的優勢：

1. 減少根證書結構的管理工作量，可以更高效的進行證書的審核與簽發。
2. 根證書一般內置在客戶端中，私鑰一般離線存儲，一旦私鑰泄露，則吊銷過程非常困難，無法及時補救。
3. 中間證書結構的私鑰泄露，則可以快速在線吊銷，并重新為用戶簽發新的證書。
4. 證書鏈四級以內一般不會對 HTTPS 的性能造成明顯影響。

證書鏈

證書鏈有以下特點：

• 同一本服務器證書可能存在多條合法的證書鏈。
  因為證書的生成和驗證基礎是公鑰和私鑰對，如果采用相同的公鑰和私鑰生成不同的中間證書，針對被簽發者而言，該簽發機構都是合法的 CA，不同的是中間證書的簽發機構不同。
• 不同證書鏈的層級不一定相同，可能二級、三級或四級證書鏈。
  中間證書的簽發機構可能是根證書機構也可能是另一個中間證書機構，所以證書鏈層級不一定相同。

證書吊銷

CA 機構能夠簽發證書，同樣也存在機制宣布以往簽發的證書無效。為何會有吊銷證書的需求呢？

• 證書使用者不合法，CA 需要廢棄該證書。
• 私鑰丟失，使用者申請讓證書無效。

那么，證書的吊銷有兩種機制：CRL 與 OCSP。

• CRL
  Certificate Revocation List，證書吊銷列表，一個單獨的文件。該文件包含了 CA 已經吊銷的證書序列號（唯一）與吊銷日期，同時該文件包含生效日期并通知下次更新該文件的時間，當然該文件必然包含 CA 私鑰的簽名以驗證文件的合法性。
  證書中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪里下載對應的 CRL 以校驗證書是否吊銷。該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書。因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。

• OCSP
  Online Certificate Status Protocol，證書狀態在線查詢協議，一個實時查詢證書是否吊銷的方式。請求者發送證書的信息并請求查詢，服務器返回正常、吊銷或未知中的任何一個狀態。證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢服務器具有良好的性能。

部分 CA 或大部分的自簽 CA 的根證書都未提供 CRL 或 OCSP 地址，對于吊銷證書會是一件非常麻煩的事情。

TLS/SSL 握手過程

1. 握手與密鑰協商過程

基于 RSA 握手和密鑰交換的客戶端驗證服務器為示例，詳解握手過程。

握手與密鑰協商

• client_hello
  客戶端發起請求，以明文傳輸請求信息。請求包含 version (版本信息) ，cipher suites (加密套件候選列表) ，compression methods (壓縮算法候選列表) ，random_C (隨機數) ，extensions (擴展字段) 等信息，相關信息如下：

• 支持的最高TSL協議版本version，從低到高依次 SSLv2 > SSLv3 > TLSv1 > TLSv1.1 > TLSv1.2，當前基本不再使用低于 TLSv1 的版本。
• 客戶端支持的加密套件 cipher suites 列表， 每個加密套件對應前面 TLS 原理中的四個功能的組合：認證算法 Au (身份驗證)、密鑰交換算法 KeyExchange (密鑰協商)、對稱加密算法 Enc (信息加密) 和信息摘要 Mac (完整性校驗)。
• 支持的壓縮算法 compression methods 列表，用于后續的信息壓縮傳輸。
• 隨機數 random_C，用于后續的密鑰的生成。
• 擴展字段 extensions，支持協議與算法的相關參數以及其它輔助信息等，常見的 SNI 就屬于擴展字段，后續單獨討論該字段作用。

• server_hello → server_certificate → sever_hello_done

• server_hello，服務端返回協商的信息結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S 等，其中隨機數用于后續的密鑰協商。
• server_certificates，服務器端配置對應的證書鏈，用于身份驗證與密鑰交換。
• server_hello_done，通知客戶端 server_hello 信息發送結束。

• 證書校驗
  客戶端驗證證書的合法性，如果驗證通過才會進行后續通信，否則根據錯誤情況不同做出提示和操作。合法性驗證包括如下：

• 證書鏈的可信性 trusted certificate path，方法如前文所述。
• 證書是否吊銷 revocation，有兩類方式 離線 CRL 與 在線 OCSP，不同的客戶端行為會不同。
• 有效期 expiry date，證書是否在有效時間范圍。
• 域名 domain，核查證書域名是否與當前的訪問域名匹配，匹配規則后續分析。

證書校驗的作用是確保客戶端獲取到 正確可信 的 服務器公鑰。對此，客戶端要做一系列的工作：驗證證書鏈，驗證吊銷狀態，驗證有效期，驗證域名。只有通過全部驗證才能保證獲取到的 服務器公鑰 → 正確可信。

• client_key_exchange → change_cipher_spec → encrypted_handshake_message

• client_key_exchange，合法性驗證通過之后，客戶端計算產生隨機數字 Pre-master，并用證書公鑰加密（用服務器公鑰加密的隨機數 Pre-master 只能服務器用自己的私鑰解開），發送給服務器。
• 客戶端已經獲取全部的計算協商密鑰需要的信息，兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商密鑰：enc_key = Fuc (random_C, random_S, Pre-Master) 。
• change_cipher_spec，客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信。
• encrypted_handshake_message，結合之前所有通信參數的 hash 值與其它相關信息生成一段數據，采用協商密鑰 session secret 與算法進行加密，然后發送給服務器用于數據與握手驗證。

• change_cipher_spec → encrypted_handshake_message

• 服務器用私鑰解密加密的 Pre-master 數據，基于之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商密鑰：enc_key = Fuc (random_C, random_S, Pre-Master) 。
• 計算之前所有接收信息的 hash 值，然后解密客戶端發送的encrypted_handshake_message，驗證數據和密鑰正確性。
• change_cipher_spec，驗證通過之后，服務器同樣發送 change_cipher_spec 以告知客戶端后續的通信都采用協商的密鑰與算法進行加密通信。
• encrypted_handshake_message，服務器也結合所有當前的通信參數信息生成一段數據并采用協商密鑰 session secret 與算法加密并發送到客戶端。

客戶端計算生成隨機數 Pre-master，用服務器公鑰加密后發給服務器。服務器獲得加密信息后用私鑰解密獲得 Pre-master。客戶端和服務器分別計算協商秘鑰 enc_key，該秘鑰用于雙方對稱加密通信使用。這里需要注意的是，在客戶端獲取到服務器公鑰并加密 Pre-master 發給服務器之前，客戶端發給服務器的隨機數 random_C 和服務器回給客戶端的隨機數 random_S 都是明文。但由于算法和 Pre-master 的存在，并不影響計算出來的 enc_key 只有客戶端和服務器持有。

客戶端發給服務器的加密信息：

• 用服務器的公鑰加密的隨機數 Pre-master 發給服務器，服務器收到后計算協商秘鑰 enc_key。

• 用協商秘鑰（對稱秘鑰）enc_key 對 client_hello 和 server_hello 中協商的相關通信參數和信息做 數字簽名（對這些信息生成摘要并加密）并發給服務器，服務器收到后用之前計算出的 enc_key 解密客戶端發來的 數字簽名 以驗證 enc_key 的正確性，如果能解開則說明協商秘鑰正確。服務器對 client_hello 和 server_hello 中的信息做哈希生成摘要，對比解密的簽名信息以驗證 雙方通信參數 的正確性。

• 握手結束
  客戶端計算所有接收信息的 hash 值，并采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成。

在（對稱）加密通信之前，準備工作（非對稱加密）中，

• 明文傳輸
  • client_hello
  • server_hello
  • change_cipher_spec

• 密文傳輸

• client_key_exchange：用服務器公鑰加密用于計算對稱秘鑰的隨機數 Pre-master 且只有擁有私鑰的服務器能解開
• encrypted_handshake_message：用協商秘鑰加密 client_hello 和 server_hello 中的信息摘要便于驗證協商秘鑰的正確性以及比對信息摘要

• 加密通信
  開始使用協商密鑰與算法進行加密通信。

注意：

• 服務器也可以要求驗證客戶端，即雙向認證，可以在過程2要發送 client_certificate_request 信息，客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經協商的通信信息得到數據，服務器可以采用對應的公鑰解密并驗證。
• 根據使用的密鑰交換算法的不同，如 ECC 等，協商細節略有不同，總體相似。
• sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基于 DH 的證書，公鑰不被證書中包含，需要單獨發送。
• change cipher spec 實際可用于通知對端改版當前使用的加密通信方式，當前沒有深入解析。
• alter message 用于指明在握手或通信過程中的狀態改變或錯誤信息，一般告警信息觸發條件是連接關閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會被斷開或者由接收方決定是否斷開連接。

2. 會話緩存握手過程

為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗（具體分析在后文），TLS 協議有兩類會話緩存機制：會話標識 session ID 與會話記錄 session ticket。

• session ID 由服務器端支持，協議中的標準字段，因此基本所有服務器都支持。服務器端保存會話 ID 以及協商的通信信息，Nginx 中 1M 內存約可以保存 4000 個 session ID 機器相關信息，占用服務器資源較多。

• session ticket 需要服務器和客戶端都支持，屬于一個擴展字段，支持范圍約 60%（無可靠統計與來源），將協商的通信信息加密之后發送給客戶端保存，密鑰只有服務器知道，占用服務器資源很少。

二者對比，主要是保存協商信息的位置與方式不同，類似于 http 中的 session 與 cookie。二者都存在的情況下，Nginx 優先使用 session_ticket。

握手過程如下圖：

回話緩存

注意：雖然握手過程有 1.5 個來回，但是最后客戶端向服務器發送的第一條應用數據不需要等待服務器返回的信息，因此握手延時是 1*RTT。

RTT ( Round-Trip Time )：往返時延。指從發送端發送數據開始，到發送端收到來自接收端的確認（接收端收到數據后便立即發送確認），總共經歷的時延。

會話標識 session ID

• 如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功后返回 session ID，并保存對應的通信參數在服務器中。
• 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中的 session ID 中攜帶記錄的信息，發送給服務器。
• 服務器根據收到的 session ID 檢索緩存記錄，如果沒有檢索到或者緩存過期，則按照正常的握手過程進行。
• 如果檢索到對應的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息。兩者作用類似，encrypted_handshake_message 是當前的通信參數與 master_secret 的 hash 值。
• 如果客戶端能夠驗證通過服務器加密數據，則客戶端向服務器同樣發送 change_cipher_spec 與 encrypted_handshake_message 信息。
• 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。

會話記錄 session ticket

• 如果客戶端和服務器之間曾經建立了連接，服務器會在 new_session_ticket 數據中攜帶加密的 session_ticket 信息，客戶端保存。
• 如果客戶端再次需要和該服務器建立連接，則在 client_hello 中擴展字段 session_ticket 中攜帶加密信息，一起發送給服務器。
• 服務器解密 sesssion_ticket 數據，如果能夠解密失敗，則按照正常的握手過程進行。
• 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用與 session ID 中類似。
• 如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送 change_cipher_spec 與encrypted_handshake_message 信息。
• 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信。

3. 重建連接

重建連接 (SSL Renegotiation)，即放棄正在使用的 TLS 連接，重新進行身份認證和密鑰協商的過程。特點是不需要斷開當前的數據傳輸就可以重新身份認證、更新密鑰或算法，因此服務器端存儲和緩存的信息都可以保持。客戶端和服務器都能夠發起重建連接的過程（目前 Windows 2000 & XP 與 SSL 2.0不支持）。

• 服務器重建連接，服務器端重建連接一般情況是客戶端訪問受保護的數據時發生。

• 客戶端和服務器之間建立了有效 TLS 連接并通信。
• 客戶端訪問受保護的信息。
• 服務器端返回 hello_request 信息。
• 客戶端收到 hello_request 信息之后發送 client_hello 信息，開始重新建立連接。

服務器重建連接

• 客戶端重建連接，客戶端重建連接一般是為了更新通信密鑰。

• 客戶端和服務器之間建立了有效 TLS 連接并通信。
• 客戶端需要更新密鑰，主動發出 client_hello 信息。
• 服務器端收到 client_hello 信息之后無法立即識別出該信息非應用數據，因此會提交給下一步處理，處理完之后會返回通知該信息為要求重建連接。
• 在確定重建連接之前，服務器不會立即停止向客戶端發送數據，可能恰好同時或有緩存數據需要發送給客戶端，但是客戶端不會再發送任何信息給服務器。
• 服務器識別出重建連接請求之后，發送 server_hello 信息至客戶端。
• 客戶端也同樣無法立即判斷出該信息非應用數據，同樣提交給下一步處理，處理之后會返回通知該信息為要求重建連接。
• 客戶端和服務器開始新的重建連接的過程。

客戶端重建連接

4. 密鑰計算

上節提到了兩個明文傳輸的隨機數 random_C 和 random_S 與通過加密在服務器和客戶端之間交換的 Pre-master，三個參數作為密鑰協商的基礎。本節討論說明密鑰協商的基本計算過程以及通信過程中的密鑰使用。

計算 Key

涉及參數 random client 和 random server，Pre-master，Master secret，key materia。計算密鑰時，服務器和客戶端都具有這些基本信息，交換方式在上節中有說明，計算流程如下：

• 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master。
• Pre-master 結合 random client 和 random server 兩個隨機數通過 PseudoRandomFunction (PRF) 計算得到 Master secret。
• Master secret 結合 random client 和 random server 兩個隨機數通過迭代計算得到 key material。

計算 key

1. PreMaster secret 前兩個字節是 TLS 的版本號，這是一個比較重要的用來核對握手數據的版本號，因為在 Client Hello 階段，客戶端會發送一份加密套件列表和當前支持的 SSL/TLS 的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之后，攻擊者很有可能串改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解。所以，服務端需要對密文中解密出來對的 PreMaster 版本號跟之前 Client Hello 階段的版本號進行對比，如果版本號變低，則說明被串改，則立即停止發送任何消息。

2. 不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于 SSL 協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。

對于 RSA 密鑰交換算法來說，pre-master-key 本身就是一個隨機數，再加上 hello 消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master 的存在在于 SSL 協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么 pre master secret 就有可能被猜出來，那么僅適用 pre master secret 作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上 pre master secret 三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。

密鑰使用

Key 經過 12 輪迭代計算會獲取到 12個 hash 值，分組成為6個元素，列表如下：

密鑰使用

• mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務器使用，但是這兩組元素都被兩邊同時獲取。
• 客戶端使用 client 組元素加密數據，服務器使用 client 元素解密；服務器使用 server 元素加密，client 使用 server 元素解密。
• 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次。
• encryption key 用于對稱加密數據。
• IV 作為很多加密算法的初始化向量使用，具體可以研究對稱加密算法。
• Mac key 用于數據的完整性校驗。

5. 數據加密通信過程

• 對應用層數據進行分片成合適的 block。
• 為分片數據編號，防止重放攻擊。
• 使用協商的壓縮算法壓縮數據。
• 計算 MAC 值和壓縮數據組成傳輸數據。
• 使用 client encryption key 加密數據，發送給服務器 server。
• server 收到數據之后使用 client encrytion key 解密，校驗數據，解壓縮數據，重新組裝。

注：MAC 值的計算包括兩個 Hash 值：client Mac key 和 Hash (編號、包類型、長度、壓縮數據)。

6. 抓包分析

關于抓包不再詳細分析，按照前面的分析，基本的情況都能夠匹配，根據平常定位問題的過程，個人提些認為需要注意的地方：

• 抓包 HTTP 通信，能夠清晰的看到通信的頭部和信息的明文，但是 HTTPS 是加密通信，無法看到 HTTP 協議的相關頭部和數據的明文信息。

• 抓包 HTTPS 通信主要包括三個過程：TCP 建立連接、TLS 握手、TLS 加密通信，主要分析 HTTPS 通信的握手建立和狀態等信息。

• client_hello

• 根據 version 信息能夠知道客戶端支持的最高的協議版本號，如果是 SSL 3.0 或 TLS 1.0 等低版本協議，非常注意可能因為版本低引起一些握手失敗的情況。
• 根據 extension 字段中的 server_name 字段判斷是否支持 SNI，存在則支持，否則不支持，對于定位握手失敗或證書返回錯誤非常有用。
• 會話標識 session ID 是標準協議部分，如果沒有建立過連接則對應值為空，不為空則說明之前建立過對應的連接并緩存。
• 會話記錄 session ticket 是擴展協議部分，存在該字段說明協議支持 sesssion ticket，否則不支持，存在且值為空，說明之前未建立并緩存連接，存在且值不為空，說明有緩存連接。

• server_hello

• 根據 TLS version 字段能夠推測出服務器支持的協議的最高版本，版本不同可能造成握手失敗。
• 基于 cipher_suite 信息判斷出服務器優先支持的加密協議。

• ceritficate
  服務器配置并返回的證書鏈，根據證書信息并與服務器配置文件對比，判斷請求與期望是否一致，如果不一致，是否返回的默認證書。

• alert
  告警信息 alert 會說明建立連接失敗的原因即告警類型，對于定位問題非常重要。

HTTPS 性能與優化

1. HTTPS 性能損耗

前文討論了 HTTPS 原理與優勢：身份驗證、信息加密與完整性校驗等，并且未對 TCP 和 HTTP 協議做任何修改。但通過增加新協議以實現更安全的通信必然需要付出代價，HTTPS 協議的性能損耗主要體現在以下兩點：

• 增加延時
  分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時 2*RTT，利用會話緩存從而復用連接，延時也至少 1*RTT。

• 消耗較多的 CPU 資源
  除數據傳輸之外，HTTPS 通信主要包括對對稱加解密、非對稱加解密（服務器主要采用私鑰解密數據）。
  壓測 TS8 機型的單核 CPU：對稱加密算法 AES-CBC-256 吞吐量 600Mbps，非對稱 RSA 私鑰解密 200次/s。不考慮其它軟件層面的開銷，10G 網卡為對稱加密需要消耗 CPU 約 17核，24 核 CPU 最多接入 HTTPS 連接 4800。
  靜態節點當前 10G 網卡的 TS8 機型的 HTTP 單機接入能力約為 10w/s，如果將所有的 HTTP 連接變為 HTTPS 連接，則明顯 RSA 的解密最先成為瓶頸。因此，RSA 的解密能力是當前困擾 HTTPS 接入的主要難題。

2. HTTPS 接入優化

• CDN 接入
  HTTPS 增加的延時主要是傳輸延時 RTT，RTT 的特點是節點越近延時越小。CDN 基于就近訪問的原則，天然離用戶最近，因此選擇使用 CDN 作為 HTTPS 接入的入口，將能夠極大減少接入延時。CDN 節點通過和業務服務器維持長連接、會話復用和鏈路質量優化等可控方法，極大減少 HTTPS 帶來的延時。

• 會話緩存
  雖然前文提到 HTTPS 即使采用會話緩存也要至少 1*RTT 的延時，但是至少延時已經減少為原來的一半，明顯的延時優化。同時，基于會話緩存建立的 HTTPS 連接不需要服務器使用 RSA 私鑰解密獲取 Pre-master 信息，可以節省 CPU 的消耗。如果業務訪問連接集中，緩存命中率高，則 HTTPS 的接入能力將明顯提升。當前 TRP 平臺的緩存命中率高峰時期大于 30%，10k/s 的接入資源實際可以承載 13k/s 的接入，收效非常可觀。

• 硬件加速
  為接入服務器安裝專用的 SSL 硬件加速卡，作用類似 GPU，釋放 CPU，能夠具有更高的 HTTPS 接入能力并且不影響業務程序。測試某硬件加速卡單卡可以提供 35k 的解密能力，相當于 175 核 CPU，至少相當于 7 臺 24 核的服務器。考慮到接入服務器其它程序的開銷，一張硬件卡可以實現接近 10 臺服務器的接入能力。

• 遠程解密（自用且規模不大不建議使用）
  采用本地接入方式消耗過多的 CPU 資源，浪費了網卡和硬盤等資源。考慮將最消耗 CPU 資源的 RSA 解密計算任務轉移到其它服務器，如此則可以充分發揮服務器的接入能力，充分利用帶寬與網卡資源。遠程解密服務器可以選擇 CPU 負載較低的機器充當，實現機器資源復用，也可以是專門優化的高計算性能的服務器。遠程解密的方式也是 CDN 提供大規模 HTTPS 接入的解決方案之一。

• SPDY/HTTP2
  前面的方法分別從減少傳輸延時和單機負載的方法提高 HTTPS 接入性能，但是方法都基于不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優勢，通過修改協議的方法來提升 HTTPS 的性能，提高下載速度等。

- END -