「開位」你所應該知道的HTTP——HTTPS篇

calimanco發表於2020-04-27
HTTP

前言

接上篇，本章主要講解HTTPS相關知識點，重點是STL/SSL的握手。

《你所應該知道的HTTP》系列的其他篇章：

概述

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

HTTPS = HTTP + TLS/SSL

HTTP協議採用明文傳輸資訊，存在資訊竊聽、資訊篡改和資訊劫持的風險，而協議TLS/SSL具有身份驗證、資訊加密和完整性校驗的功能，可以避免此類問題發生。
TLS全稱Transport Layer Security（安全傳輸層協議）, 前身是SSL，故現在用TLS/SSL統稱。是介於TCP和HTTP之間的一層安全協議，不影響原有的TCP協議和HTTP協議，所以使用HTTPS基本上不需要對HTTP頁面進行太多的改造。

套用在TCP/IP四層模型裡的結構如下：
模型

TLS/SSL原理

TLS/SSL的功能實現主要依賴於三類基本演算法：雜湊函式（Hash）、對稱加密和非對稱加密。
其利用非對稱加密實現身份認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函式驗證資訊的完整性。

TLS/SSL = 非對稱加密 + 對稱加密 + 雜湊演算法

非對稱加密

加密和解密使用不同金鑰的加密演算法，也稱為公私鑰加密。金鑰成對出現，一般稱為公鑰（publickey）和私鑰（privatekey），公鑰加密的資訊只能私鑰解開，私鑰加密的資訊只能公鑰解開。即伺服器持有私鑰，客戶端持有公鑰，客戶端要傳送的資訊經過公鑰加密後傳遞給伺服器，伺服器用私鑰解密得到明文資訊。

特點：

  • 可以實現1對多的通訊；
  • 保密性比較好，只有公鑰需要被傳遞，故私鑰被劫持的概率很低；
  • 安全性高，保密性保證私鑰安全，因此安全性僅依賴於演算法本身；
  • 計算複雜，加密速度慢。

在TLS/SSL中，非對稱加密僅用於“身份認證”和“金鑰協商”，不在後續正文資料傳輸中使用，這是安全性與效能之間的平衡取捨。

對稱加密

加密和解密使用相同金鑰的加密演算法。即客戶端與伺服器所持有的金鑰是相同的，客戶端要傳送的資訊經過金鑰加密後傳遞給伺服器，伺服器用相同金鑰解密得到明文資訊。

特點：

  • 通訊方式是1對1，為了足夠安全，伺服器和N個客戶端通訊，需要維持N個密碼記錄；
  • 安全性不僅取決於加密演算法本身，金鑰管理的安全性更是重要；
  • 計算量小、加密速度快、加密效率高；
  • 缺少吊銷和修改金鑰的機制。

在TLS/SSL中，對稱加密的金鑰是通過非對稱加密的“金鑰協商”產生的，這樣就最大限度的保證了金鑰的安全。由於其效率高的特點，正文資料傳輸使用了該加密方式。

雜湊函式（Hash）

一種將任意長度的訊息壓縮到某一固定長度的訊息摘要的函式，常用於防止資訊篡改並驗證資料的完整性。

特點：

  • 單向不可逆；
  • 對輸入非常敏感，即一點輸入的改變都會導致結果不同；
  • 輸出長度固定。

在資訊傳輸過程中，雜湊函式不能單獨實現資訊防篡改，因為明文傳輸，中間人可以修改資訊之後重新計算資訊摘要，因此需要對傳輸的資訊以及資訊摘要進行加密。
在TLS/SSL中，“金鑰協商”的最後步驟和傳輸正文資訊都會帶上雜湊函式計算出的資訊摘要，他們一起經過對稱加密後傳輸，用來驗證完整性。

PKI體系

非對稱加密的隱患

前面講到“身份驗證”和“金鑰協商”是TLS/SSL的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但非對稱加密演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊。
假定出現以下的情況：

  • 客戶端C和伺服器S進行通訊，中間節點M截獲了二者的通訊;
  • 節點M自己計算產生一對公鑰pub_M和私鑰pri_M;
  • C向S請求公鑰時，M把自己的公鑰pub_M發給了C;
  • C使用公鑰pub_M加密的資料能夠被M解密，因為M掌握對應的私鑰pri_M，而C無法根據公鑰資訊判斷伺服器的身份，從而C和M之間建立了"可信"加密連線。

中間人攻擊.png

如圖，中間節點M和伺服器S之間再建立合法的連線，因此C和S之間通訊被M完全掌握，M可以進行資訊的竊聽、篡改等操作，這類攻擊被稱為“中間人攻擊”。

身份驗證CA和證書

為了解決上述的隱患，關鍵是確保獲取公鑰途徑是合法的，能夠驗證伺服器的身份資訊，為此需要引入權威的第三方機構CA。
CA全稱Certificate Authority（證書頒發機構），它負責核實公鑰的擁有者的資訊，並頒發認證"證書"，同時能夠為使用者提供證書驗證服務，即PKI體系。

證書 = 公鑰 + 申請者與頒發者資訊 + 有效時間 + 域名資訊 + 簽名

CA認證流程如下：
PKI.png

客戶端會內建信任CA的證書資訊（包含公鑰），如果CA不被信任，則找不到對應CA的證書，證書也會被判定非法。
也可以這樣理解，網站千千萬，瀏覽器廠商沒辦法一家一家去認證，於是跟CA合作，通過維護一個CA列表，只要網站有經過這個列表裡CA的認證，就可以信任該網站的證書。

TLS/SSL握手過程

TLS/SSL握手過程也就是所謂的HTTPS四次握手（不含證書驗證步驟）。

  1. 客戶端發起請求，以明文傳輸請求資訊，包含版本資訊，加密套件候選列表，壓縮演算法候選列表，隨機數random_C（明文），擴充套件欄位等資訊。
  2. 服務端返回協商的資訊結果，隨機數random_S（明文），證書鏈等。
  3. 對證書進行驗證，包括證書可信性、有效性等，可能需要聯絡CA。

  4. 細分為四步：

    1. client_key_exchange：客戶端計算產生隨機數字Pre-master，並用證書公鑰加密，傳送給伺服器;
    2. 客戶端根據random_C、random_S以及Pre-master，計算得到協商金鑰enc_key（即對稱加密用的金鑰）；
    3. change_cipher_spec：客戶端通知伺服器後續的通訊都採用協商的通訊金鑰和加密演算法進行加密通訊;
    4. encrypted_handshake_message：結合之前所有通訊引數的hash值與其它相關資訊生成一段資料，採用協商金鑰enc_key進行加密，然後傳送給伺服器用於資料與握手驗證;

  5. 細分為四步：

    1. 伺服器使用私鑰解密Pre-master，根據random_C、random_S以及Pre-master，計算得到協商金鑰enc_key；
    2. 計算之前所有接收資訊的hash值，然後解密客戶端傳送的encrypted_handshake_message，驗證資料和金鑰正確性；
    3. change_cipher_spec：驗證通過之後，伺服器同樣傳送change_cipher_spec以告知客戶端後續的通訊都採用協商的金鑰與演算法進行加密通訊;
    4. encrypted_handshake_message：伺服器也結合所有當前的通訊引數資訊生成一段資料並採用協商金鑰enc_key加密併傳送到客戶端;
  6. 握手結束，開始使用協商金鑰enc_key進行對稱加密通訊（包含hash完整性驗證）。

示意圖如下：
TLS握手.png

HTTPS的使用成本

  • 證書費用及維護更新
    一般正規CA頒發的證書都是需要付費購買的，並且到期後還得續費。
  • 增加了訪問延遲
    分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通訊，至少增加延時2RTT，利用會話快取從而複用連線，延時也至少1RTT。
  • 消耗較多CPU資源
    加解密是需要消耗效能的，前面也有提到非對稱加密的特點，因此會成為效能瓶頸。

HTTPS的優化

TLS False Start

在TLS/SSL協商第二階段，也就是瀏覽器生成最後一個隨機數並用公鑰加密傳送給伺服器後，立即傳送加密的應用層資料，而無需等待伺服器的確認。

Session Identifier（會話識別符號）

如果使用者的一個業務請求包含了多條的加密流，客戶端與伺服器要反覆握手，必定導致更多的時間損耗。或某些特殊情況導致會話中斷，需要重新握手。
伺服器為每一次的會話生成並記錄一個sessionId，傳送給客戶端，客戶端重新連線只需要提供這個id，不需要重新握手。

OCSP Stapling

OCSP全稱Online Certificate Status Protocol。由web伺服器向OCSP server週期性地查詢證書狀態，獲得一個帶有時間戳和簽名的OCSP response並快取它。當有客戶端發起請求時，web伺服器會把這個response在TLS握手過程中發給客戶端。
（谷歌瀏覽器預設只使用內建列表檢查，故這個優化對谷歌無效）

HSTS（HTTP Strict-Transport-Security）

一個報文頭部欄位，告訴瀏覽器，接下來的一段時間內，當前域名(及其子域名)的後續通訊應該強制性使用HTTPS，直到超過有效期為止。

形如：

Strict-Transport-Security: max-age=31536000;includeSubDomains

相關文章