HTTPS篇
前言
接上篇，本章主要講解HTTPS相關知識點，重點是STL/SSL的握手。
概述
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認證流程如下：
客戶端會內置信任CA的證書信息（包含公鑰），如果CA不被信任，則找不到對應CA的證書，證書也會被判定非法。
也可以這樣理解，網站千千萬，瀏覽器廠商沒辦法一家一家去認證，於是跟CA合作，通過維護一個CA列表，只要網站有經過這個列表裏CA的認證，就可以信任該網站的證書。
TLS/SSL握手過程
TLS/SSL握手過程也就是所謂的HTTPS四次握手（不含證書驗證步驟）。
-
客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數random_C（明文），擴展字段等信息。
-
服務端返回協商的信息結果，隨機數random_S（明文），證書鏈等。
-
對證書進行驗證，包括證書可信性、有效性等，可能需要聯繫CA。
-
細分爲四步：
- client_key_exchange：客戶端計算產生隨機數字Pre-master，並用證書公鑰加密，發送給服務器;
- 客戶端根據random_C、random_S以及Pre-master，計算得到協商密鑰enc_key（即對稱加密用的密鑰）；
- change_cipher_spec：客戶端通知服務器後續的通信都採用協商的通信密鑰和加密算法進行加密通信;
- encrypted_handshake_message：結合之前所有通信參數的hash值與其它相關信息生成一段數據，採用協商密鑰enc_key進行加密，然後發送給服務器用於數據與握手驗證;
-
細分爲四步：
- 服務器使用私鑰解密Pre-master，根據random_C、random_S以及Pre-master，計算得到協商密鑰enc_key；
- 計算之前所有接收信息的hash值，然後解密客戶端發送的encrypted_handshake_message，驗證數據和密鑰正確性；
- change_cipher_spec：驗證通過之後，服務器同樣發送change_cipher_spec以告知客戶端後續的通信都採用協商的密鑰與算法進行加密通信;
- encrypted_handshake_message：服務器也結合所有當前的通信參數信息生成一段數據並採用協商密鑰enc_key加密併發送到客戶端;
-
握手結束，開始使用協商密鑰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
後記
想要了解更多關注我哦
