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

前言

接上篇，HTTPS是現代平常使用十分頻繁的HTTP相關技術，但自己原理上與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之間創建了"可信"加密鏈接。

如圖，中間節點M和服務器S之間再創建合法的鏈接，所以C和S之間通訊被M徹底掌握，M能夠進行信息的竊聽、篡改等操做，這類攻擊被稱爲「中間人攻擊」。

身份驗證CA和證書

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

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

CA認證流程以下：

客戶端會內置信任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完整性驗證）。

示意圖以下：

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