（5）HTTPS加密協議詳解

阿新 • • 發佈：2018-12-04

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和HTTP的區別:

1、HTTPS是加密傳輸協議，HTTP是明文傳輸協議;

2、HTTPS需要用到SSL證書，而HTTP不用;

3、HTTPS比HTTP更加安全，對搜尋引擎更友好，利於SEO,參考：

（1）為保護使用者隱私安全,谷歌優先索引HTTPS網頁

（2）百度開放收錄https站點，https全網化勢不可擋

4、 HTTPS標準埠443，HTTP標準埠80;

5、 HTTPS基於傳輸層，HTTP基於應用層;

6、 HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

使用HTTPS加密的7大理由

1、HTTPS加密使網站速度更快

2、HTTP/2協議只支援HTTPS加密連線

3、HTTP頁面將標記“不安全”

4、HTTPS加密提升搜尋排名

5、HTTPS加密防止中間人流量劫持

6、iOS和安卓都要求使用HTTPS加密

7、超級許可權應用禁止使用HTTP連線

二、SSL/TLS概述

SSL/TLS是一個介於HTTP協議與TCP之間的一個可選層。

SSL/TLS協議層

SSL

SSL（Secure Socket Layer，安全套接字層），為Netscape所研發，用以保障在Internet上資料傳輸之安全，利用資料加密(Encryption)技術，可確保資料在網路上之傳輸過程中不會被擷取。當前版本為3.0。它已被廣泛地用於Web瀏覽器與伺服器之間的身份認證和加密資料傳輸。

SSL協議位於TCP/IP協議與各種應用層協議之間，為資料通訊提供安全支援。

SSL協議可分為兩層：

SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。
SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。

TLS

TLS(Transport Layer Security，傳輸層安全協議)，用於兩個應用程式之間提供保密性和資料完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的後續版本，可以理解為SSL 3.1，它是寫入了 RFC 的。

該協議由兩層組成：

TLS 握手協議（TLS Handshake）：1) 握手協議；2）密碼規格變更協議；3）警告協議； 4）應用資料協議。
TLS 記錄協議（TLS Record）較低的層為 TLS 記錄協議，它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援，定義了傳輸的格式。
- 將訊息分割為多個片段
- 對每個片段進行壓縮
- 加上片段編號(防止重放攻擊)計算訊息驗證碼MAC值(保證資料完整性)，追加在壓縮片段
- 對稱密碼加密
- 加上資料型別、版本號、壓縮後的長度組成的報頭，就是最終的報文資料

SSL/TLS協議提供的服務主要有：

認證使用者和伺服器，確保資料傳送到正確的客戶機和伺服器；
加密資料以防止資料中途被竊取；
維護資料的完整性，確保資料在傳輸過程中不被改變。

三、加密概念

加密是通過 Intranet、Extranet 和 Internet 進行安全的資訊交換的基礎。從業務的角度來看，通過加密實現的安全功能包括：身份驗證，使收件人確信發件人就是他或她所宣告的那個人; 機密性，確保只有預期的收件人能夠閱讀郵件;以及 完整性 ，確保郵件在傳輸過程中沒有被更改。從技術的角度來看，加密是利用數學方法將郵件轉換為不可讀格式從而達到保護資料的目的的一門科學。

對稱金鑰加密：一個金鑰

對稱金鑰加密，使用相同的金鑰和演算法進行加解密。對稱金鑰加密是加密大量資料的一種行之有效的方法。常見的演算法有 DES，3DES，Blowfish，RC5，AES等。

對稱金鑰加密的優點是速度快、安全、緊湊，缺點是:

明文傳輸共享金鑰，容易出現中途劫持和竊聽的問題。
金鑰數量是以參與者數量平方的速度增長（指數增長n(n-1)/2）。
因為數量過多，所以管理和儲存會有很大問題。
不支援數字簽名和不可否認性。

非對稱金鑰加密：兩個金鑰

非對稱金鑰加密（公鑰加密）使用兩個金鑰，一個公鑰和一個私鑰。在非對稱金鑰加密中，公鑰可在通訊雙方之間公開傳遞，或在公用儲備庫中釋出，但相關的私鑰是保密的。只有使用私鑰才能解密用公鑰加密的資料，使用私鑰加密的資料只能用公鑰解密。

非對稱金鑰加密的優點:

安全，因為不必傳送金鑰給接受者，所以非對稱加密不必擔心金鑰被中途截獲的問題。
金鑰數目和參與者的數目一樣。
不需要事先在各參與者之間建立關係以交換金鑰。
技術支援數字簽名和不可否認性。

缺點:

非常非常慢。
密文會變長。

非對稱金鑰加密僅僅只用於:金鑰交換（加密金鑰）和數字簽名（加密雜湊）。

非對稱金鑰演算法有RSA、Elgamal、揹包演算法、Rabin、HD,ECC（橢圓曲線加密演算法）。

RSA -適用於數字簽名和金鑰交換。 RSA 演算法的安全性基於分解大數字時的困難(就計算機處理能力和處理時間而言)。
DSA -僅適用於數字簽名。 DSA 演算法的安全性源自計算離散演算法的困難。
Diffie-Hellman -僅適用於金鑰交換。 Diffie-Hellman 演算法的安全性源自在一個有限欄位中計算離散演算法的困難。

單向雜湊演算法

雜湊Hash演算法是一種單向演算法，可將任意長度的一塊資料轉換為一個定長的、不可逆轉的數字。

通過雜湊函式計算得到的結果叫做雜湊值或資訊摘要，這個雜湊值也常常被稱為資料的指紋（Fingerprint）。

常見的雜湊函式有 MD5（128位）、SHA1（160位）、SHA256（256位），該類函式特點是函式單向不可逆、對輸入非常敏感、輸出長度固定，針對資料的任何修改都會改變雜湊函式的結果，用於防止資訊篡改並驗證資料的完整性。

在資訊傳輸過程中，雜湊函式不能單獨實現資訊防篡改，因為明文傳輸，中間人可以修改資訊之後重新計算雜湊值，因此需要對傳輸的資訊以及雜湊值進行加密。

數字簽名：結合使用公鑰與雜湊演算法

數字簽名是郵件、檔案或其它數字編碼資訊的發件人將他們的身份與資訊繫結在一起(即為資訊提供簽名)的方法。對資訊進行數字簽名的過程，需要將資訊與由發件人掌握的祕密資訊一起轉換為叫做簽名的標記。數字簽名用於公鑰環境中，它通過驗證發件人確實是他或她所宣告的那個人，並確認收到的郵件與傳送的郵件完全相同，來幫助確保電子商務交易的安全。

通常，數字簽名用於以明文(如電子郵件)分發資料的情形。在這種情況下，當郵件本身的敏感性可能無法保證加密的安全性時，確保資料處於其原始格式且並非由假冒者傳送，是非常重要的。

可以結合使用公鑰技術與雜湊演算法來建立數字簽名。數字簽名可用作資料完整性檢查並提供擁有私鑰的憑據。

數字簽名簽署和驗證資料的步驟如下：

發件人將一種雜湊演算法應用於資料，並生成一個雜湊值。
發件人使用私鑰將雜湊值轉換為數字簽名。
然後，發件人將資料、簽名及發件人的證書發給收件人。
收件人將該雜湊演算法應用於接收到的資料，並生成一個雜湊值。
收件人使用發件人的公鑰和新生成的雜湊值驗證簽名。

雜湊演算法處理資料的速度比公鑰演算法快得多。雜湊資料還縮短了要簽名的資料的長度，因而加快了簽名過程。當建立或驗證簽名時，公鑰演算法必須且只需轉換雜湊值(128 或 160 位的資料)。建立簽名和驗證簽名的詳細步驟取決於所採用的公鑰演算法。

金鑰交換：結合使用對稱金鑰與公鑰

對稱金鑰演算法非常適合於快速並安全地加密資料。但其缺點是，發件人和收件人必須在交換資料之前先交換機密金鑰。結合使用加密資料的對稱金鑰演算法與交換機密金鑰的公鑰演算法可產生一種既快速又靈活的解決方案。

基於公鑰的金鑰交換步驟如下：

發件人獲得收件人的公鑰。
發件人建立一個隨機機密金鑰(在對稱金鑰加密中使用的單個金鑰)。
發件人使用機密金鑰和對稱金鑰演算法將明文資料轉換為暗文資料。
發件人使用收件人的公鑰將機密金鑰轉換為暗文機密金鑰。
發件人將暗文資料和暗文機密金鑰一起發給收件人。
收件人使用其私鑰將暗文機密金鑰轉換為明文。
收件人使用明文機密金鑰將暗文資料轉換為明文資料。

四、TLS/SSL工作原理

HTTPS協議的主要功能基本都依賴於TLS/SSL協議，本節分析TLS/SSL協議工作原理。

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

TLS的基本工作方式是，客戶端使用非對稱加密與伺服器進行通訊，實現身份驗證並協商對稱加密使用的金鑰，然後對稱加密演算法採用協商金鑰對資訊以及資訊摘要進行加密通訊，不同的節點之間採用的對稱金鑰不同，從而可以保證資訊只能通訊雙方獲取。

TLS/SSL工作原理

五、PKI 體系

公鑰機制PKI的概念：採用證書管理公鑰,通過CA (Certificate Authority)，把要傳輸的資訊進行加密和簽名，保證資訊傳輸的機密性、真實性、完整性和不可否認性，從而保證資訊的安全傳輸。

PKI組成：CA(certification authority，認證中心,負責發放，管理和撤銷數字證書的權威機構)、RA(registration authority，註冊審批機構，負責證書申請，稽核等工作)、證書庫、金鑰恢復伺服器和終端使用者。

1、RSA身份驗證的隱患

身份驗證和金鑰協商是TLS的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但RSA演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊，存在安全隱患:

客戶端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可以進行資訊的竊聽、篡改等操作。
另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。

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

中間人攻擊和資訊抵賴

2、身份驗證CA和證書

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

基本的原理為，CA負責稽核資訊，然後對關鍵資訊利用私鑰進行"簽名"，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 檔案和 OCSP。CA使用具體的流程如下：

身份驗證CA和證書

a.服務方S向第三方機構CA提交公鑰、組織資訊、個人資訊(域名)等資訊並申請認證;

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

c.如資訊稽核通過，CA會向申請者簽發認證檔案-證書。

證書包含以下資訊：申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 CA的資訊、有效時間、證書序列號等資訊的明文，同時包含一個簽名;

簽名的產生演算法：首先，使用雜湊函式計算公開的明文資訊的資訊摘要，然後，採用 CA的私鑰對資訊摘要進行加密，密文即簽名;

d.客戶端 C 向伺服器 S 發出請求時，S 返回證書檔案;

e.客戶端 C讀取證書中的相關的明文資訊，採用相同的雜湊函式計算得到資訊摘要，然後，利用對應 CA的公鑰解密簽名資料，對比證書的資訊摘要，如果一致，則可以確認證書的合法性，即公鑰合法;

f.客戶端然後驗證證書相關的域名資訊、有效時間等資訊;

g.客戶端會內建信任CA的證書資訊(包含公鑰)，如果CA不被信任，則找不到對應 CA的證書，證書也會被判定非法。

在這個過程注意幾點：

a.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握;

b.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名;

c.內建 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書（為什麼說"部署自籤SSL證書非常不安全"）

d.證書=公鑰+申請者與頒發者資訊+簽名;

主流的證書格式為X.509。

3、證書鏈

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

a.伺服器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書;

b.中間證書 inter.pem 的簽發 CA 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書;

c.客戶端內建信任 CA 的 root.pem 證書，因此伺服器證書 server.pem 的被信任。

證書鏈

伺服器證書、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。

二級證書結構存在的優勢：

a.減少根證書結構的管理工作量，可以更高效的進行證書的稽核與簽發;

b.根證書一般內建在客戶端中，私鑰一般離線儲存，一旦私鑰洩露，則吊銷過程非常困難，無法及時補救;

c.中間證書結構的私鑰洩露，則可以快速線上吊銷，並重新為使用者簽發新的證書;

d.證書鏈四級以內一般不會對 HTTPS 的效能造成明顯影響。

二級證書結構

證書鏈有以下特點：

a.同一本伺服器證書可能存在多條合法的證書鏈。

因為證書的生成和驗證基礎是公鑰和私鑰對，如果採用相同的公鑰和私鑰生成不同的中間證書，針對被簽發者而言，該簽發機構都是合法的 CA，不同的是中間證書的簽發機構不同;

b.不同證書鏈的層級不一定相同，可能二級、三級或四級證書鏈。

中間證書的簽發機構可能是根證書機構也可能是另一箇中間證書機構，所以證書鏈層級不一定相同。

4、證書吊銷

CA 機構能夠簽發證書，同樣也存在機制宣佈以往簽發的證書無效。證書使用者不合法，CA 需要廢棄該證書;或者私鑰丟失，使用者申請讓證書無效。主要存在兩類機制：CRL 與 OCSP。

a.CRL

Certificate Revocation List, 證書吊銷列表，一個單獨的檔案。該檔案包含了 CA 已經吊銷的證書序列號(唯一)與吊銷日期，同時該檔案包含生效日期並通知下次更新該檔案的時間，當然該檔案必然包含 CA 私鑰的簽名以驗證檔案的合法性。

證書中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪裡下載對應的 CRL 以校驗證書是否吊銷。該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。

b.OCSP

Online Certificate Status Protocol, 證書狀態線上查詢協議，一個實時查詢證書是否吊銷的方式。請求者傳送證書的資訊並請求查詢，伺服器返回正常、吊銷或未知中的任何一個狀態。證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢伺服器具有良好的效能。部分 CA 或大部分的自籤 CA (根證書)都是未提供 CRL 或 OCSP 地址的，對於吊銷證書會是一件非常麻煩的事情。

六、TLS/SSL握手過程

1、握手與金鑰協商過程

基於RSA握手和金鑰交換的客戶端驗證伺服器為示例詳解TLS/SSL握手過程。

TLS/SSL握手過程

開始加密通訊之前，客戶端和伺服器首先必須建立連線和交換引數，這個過程叫做握手（handshake）。

(1)client_hello

客戶端發起請求，以明文傳輸請求資訊，包含版本資訊，加密套件候選列表，壓縮演算法候選列表，隨機數，擴充套件欄位等資訊，相關資訊如下：

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

加密套件

加密套件（CipherList）是指在ssl/tls通訊中，伺服器和客戶端所使用的加密演算法的組合。

金鑰交換：用於決定客戶端與伺服器之間在握手的過程中如何認證。使用非對稱加密演算法來生成會話金鑰，因為非對稱演算法不會將重要資料在通訊中傳輸用到的演算法包括RSA，Diffie-Hellman，ECDH，PSK等
加密演算法：主要是對傳輸的資料進行加密傳輸用的。一般有對稱加和非對稱加密；所以真正要傳輸的資料會使用對稱加密來進行加密。演算法名稱後通常會帶有兩個數字，分別表示金鑰的長度和初始向量的長度，比如DES 56/56, RC2 56/128, RC4 128/128, AES 128/128, AES 256/256；
會話校驗（MAC）演算法，為了防止握手本身被竄改（這裡極容易和證書籤名演算法混淆）。演算法包括MD5，SHA等
PRF（偽隨機數函式），用於生成“master secret”

加密套件格式示例：

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

從其名字可知，它是：

基於TLS協議的；
使用ECDHE、RSA作為金鑰交換演算法；
加密演算法是AES（金鑰和初始向量的長度都是256）；
MAC演算法（這裡就是雜湊演算法）是SHA。

(2)server_hello+server_certificate+sever_hello_done

(a) server_hello, 服務端返回協商的資訊結果，包括選擇使用的協議版本 version，選擇的加密套件 cipher suite，選擇的壓縮演算法 compression method、隨機數 random_S 等，其中隨機數用於後續的金鑰協商;

(b)server_certificates, 伺服器端配置對應的證書鏈，用於身份驗證與金鑰交換;

(3)證書校驗

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

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

(4)client_key_exchange+change_cipher_spec+encrypted_handshake_message

(a) client_key_exchange，合法性驗證通過之後，客戶端計算產生隨機數字 Pre-master，並用證書公鑰加密，傳送給伺服器;

(b) 此時客戶端已經獲取全部的計算協商金鑰需要的資訊：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商金鑰;

enc_key=Fuc(random_C, random_S, Pre-Master)

(d) encrypted_handshake_message，結合之前所有通訊引數的 hash 值與其它相關資訊生成一段資料，採用協商金鑰 session secret 與演算法進行加密，然後傳送給伺服器用於資料與握手驗證;

(5)change_cipher_spec+encrypted_handshake_message

(a) 伺服器用私鑰解密加密的 Pre-master 資料，基於之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商金鑰:enc_key=Fuc(random_C, random_S, Pre-Master);

(b) 計算之前所有接收資訊的 hash 值，然後解密客戶端傳送的 encrypted_handshake_message，驗證資料和金鑰正確性;

(d) encrypted_handshake_message, 伺服器也結合所有當前的通訊引數資訊生成一段資料並採用協商金鑰 session secret 與演算法加密併發送到客戶端;

(6)握手結束

客戶端計算所有接收資訊的 hash 值，並採用協商金鑰解密 encrypted_handshake_message，驗證伺服器傳送的資料和金鑰，驗證通過則握手完成;

(7)加密通訊

開始使用協商金鑰與演算法進行加密通訊。

注意：

(a) 伺服器也可以要求驗證客戶端，即雙向認證，可以在過程2要傳送 client_certificate_request 資訊，客戶端在過程4中先發送 client_certificate與certificate_verify_message 資訊，證書的驗證方式基本相同，certificate_verify_message 是採用client的私鑰加密的一段基於已經協商的通訊資訊得到資料，伺服器可以採用對應的公鑰解密並驗證;

(b) 根據使用的金鑰交換演算法的不同，如 ECC 等，協商細節略有不同，總體相似;

(d) change cipher spec 實際可用於通知對端改版當前使用的加密通訊方式，當前沒有深入解析;

(e) alter message 用於指明在握手或通訊過程中的狀態改變或錯誤資訊，一般告警資訊觸發條件是連線關閉，收到不合法的資訊，資訊解密失敗，使用者取消操作等，收到告警資訊之後，通訊會被斷開或者由接收方決定是否斷開連線。

總結：

SSL客戶端（也是TCP的客戶端）在TCP連線建立之後，發出一個ClientHello來發起握手，這個訊息裡面包含了自己可實現的演算法列表和其它一些需要的訊息，SSL的伺服器端會迴應一個ServerHello，這裡面確定了這次通訊所需要的演算法，然後發過去自己的證書（裡面包含了身份和自己的公鑰）。Client在收到這個訊息後會生成一個祕密訊息，用SSL伺服器的公鑰加密後傳過去，SSL伺服器端用自己的私鑰解密後，會話金鑰協商成功，雙方可以用同一份會話金鑰來通訊了。

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。

(1)會話標識 session ID

(a) 如果客戶端和伺服器之間曾經建立了連線，伺服器會在握手成功後返回 session ID，並儲存對應的通訊引數在伺服器中;

(b) 如果客戶端再次需要和該伺服器建立連線，則在 client_hello 中 session ID 中攜帶記錄的資訊，傳送給伺服器;

(d) 如果檢索到對應的快取記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 資訊，兩個資訊作用類似，encrypted_handshake_message 是到當前的通訊引數與 master_secret的hash 值;

(f) 如果客戶端能夠驗證通過伺服器加密資料，則客戶端同樣傳送 change_cipher_spec 與 encrypted_handshake_message 資訊;

(g) 伺服器驗證資料通過，則握手建立成功，開始進行正常的加密資料通訊。

(2)會話記錄 session ticket

(a) 如果客戶端和伺服器之間曾經建立了連線，伺服器會在 new_session_ticket 資料中攜帶加密的 session_ticket 資訊，客戶端儲存;

(b) 如果客戶端再次需要和該伺服器建立連線，則在 client_hello 中擴充套件欄位 session_ticket 中攜帶加密資訊，一起傳送給伺服器;

(d) 如果解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 資訊，兩個資訊作用與 session ID 中類似;

(f)如果客戶端能夠驗證通過伺服器加密資料，則客戶端同樣傳送 change_cipher_spec與encrypted_handshake_message 資訊;

(g) 伺服器驗證資料通過，則握手建立成功，開始進行正常的加密資料通訊。

3、重建連線

重建連線 renegotiation 即放棄正在使用的 TLS 連線，從新進行身份認證和金鑰協商的過程，特點是不需要斷開當前的資料傳輸就可以重新身份認證、更新金鑰或演算法，因此伺服器端儲存和快取的資訊都可以保持。客戶端和伺服器都能夠發起重建連線的過程。

(1)伺服器重建連線

伺服器重建連線

伺服器端重建連線一般情況是客戶端訪問受保護的資料時發生。基本過程如下：

(a) 客戶端和伺服器之間建立了有效 TLS 連線並通訊;

(b) 客戶端訪問受保護的資訊;

(d) 客戶端收到 hello_request 資訊之後傳送 client_hello 資訊，開始重新建立連線。

(2)客戶端重建連線

客戶端重建連線

客戶端重建連線一般是為了更新通訊金鑰。

(a) 客戶端和伺服器之間建立了有效 TLS 連線並通訊;

(b) 客戶端需要更新金鑰，主動發出 client_hello 資訊;

(d) 在確定重建連線之前，伺服器不會立即停止向客戶端傳送資料，可能恰好同時或有快取資料需要傳送給客戶端，但是客戶端不會再發送任何資訊給伺服器;

(e) 伺服器識別出重建連線請求之後，傳送 server_hello 資訊至客戶端;

(f) 客戶端也同樣無法立即判斷出該資訊非應用資料，同樣提交給下一步處理，處理之後會返回通知該資訊為要求重建連線;

(g) 客戶端和伺服器開始新的重建連線的過程。

4、金鑰計算

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

(1)計算 Key

涉及引數 random client 和 random server, Pre-master, Master secret, key material, 計算金鑰時，伺服器和客戶端都具有這些基本資訊，交換方式在上節中有說明，計算流程如下：

金鑰計算流程

(a) 客戶端採用 RSA 或 Diffie-Hellman 等加密演算法生成 Pre-master;

(b) Pre-master 結合 random client 和 random server 兩個隨機數通過 PseudoRandomFunction(PRF)計算得到 Master secret;

以下為一些重要的記錄，可以解決部分愛深入研究朋友的疑惑，copy的材料，分享給大家：

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

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

對於 RSA 金鑰交換演算法來說，pre-master-key 本身就是一個隨機數，再加上 hello 訊息中的隨機，三個隨機數通過一個金鑰匯出器最終匯出一個對稱金鑰。

pre master 的存在在於 SSL 協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那麼 pre master secret 就有可能被猜出來，那麼僅適用 pre master secret 作為金鑰就不合適了，因此必須引入新的隨機因素，那麼客戶端和伺服器加上 pre master secret 三個隨機數一同生成的金鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。

(2)金鑰使用

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

金鑰使用

(a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和伺服器使用，但是這兩組元素都被兩邊同時獲取;

(b) 客戶端使用 client 組元素加密資料，伺服器使用 client 元素解密;伺服器使用 server 元素加密，client 使用 server 元素解密;

(d) encryption key 用於對稱加密資料;

(e) IV 作為很多加密演算法的初始化向量使用，具體可以研究對稱加密演算法;

(f) Mac key 用於資料的完整性校驗;

(3)資料加密通訊過程

(a) 對應用層資料進行分片成合適的 block;

(b) 為分片資料編號，防止重放攻擊;

(d) 計算 MAC 值和壓縮資料組成傳輸資料;

(e) 使用 client encryption key 加密資料，傳送給伺服器 server;

(f) server 收到資料之後使用 client encrytion key 解密，校驗資料，解壓縮資料，重新組裝。

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

5、抓包分析

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

(1)抓包 HTTP 通訊，能夠清晰的看到通訊的頭部和資訊的明文，但是 HTTPS 是加密通訊，無法看到 HTTP 協議的相關頭部和資料的明文資訊，

(2)抓包 HTTPS 通訊主要包括三個過程：TCP 建立連線、TLS 握手、TLS 加密通訊，主要分析 HTTPS 通訊的握手建立和狀態等資訊。

(3)client_hello

根據 version 資訊能夠知道客戶端支援的最高的協議版本號，如果是 SSL 3.0 或 TLS 1.0 等低版本協議，非常注意可能因為版本低引起一些握手失敗的情況;

根據 extension 欄位中的 server_name 欄位判斷是否支援SNI，存在則支援，否則不支援，對於定位握手失敗或證書返回錯誤非常有用;

會話標識 session ID 是標準協議部分，如果沒有建立過連線則對應值為空，不為空則說明之前建立過對應的連線並快取;

會話記錄 session ticke t是擴充套件協議部分，存在該欄位說明協議支援 sesssion ticket，否則不支援，存在且值為空，說明之前未建立並快取連線，存在且值不為空，說明有快取連線。

(4)server_hello

根據 TLS version 欄位能夠推測出伺服器支援的協議的最高版本，版本不同可能造成握手失敗;

基於 cipher_suite 資訊判斷出伺服器優先支援的加密協議;

(5)ceritficate

伺服器配置並返回的證書鏈，根據證書資訊並於伺服器配置檔案對比，判斷請求與期望是否一致，如果不一致，是否返回的預設證書。

(6)alert

告警資訊 alert 會說明建立連線失敗的原因即告警型別，對於定位問題非常重要。

七、HTTPS效能與優化

1、HTTPS效能損耗

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

(1)增加延時

分析前面的握手過程，一次完整的握手至少需要兩端依次來回兩次通訊，至少增加延時2* RTT，利用會話快取從而複用連線，延時也至少1* RTT*。

(2)消耗較多的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接入優化

(1)CDN接入

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

(2)會話快取

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

(3)硬體加速

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

(4)遠端解密

本地接入消耗過多的 CPU 資源，浪費了網絡卡和硬碟等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它伺服器，如此則可以充分發揮伺服器的接入能力，充分利用頻寬與網絡卡資源。遠端解密伺服器可以選擇 CPU 負載較低的機器充當，實現機器資源複用，也可以是專門優化的高計算效能的伺服器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。

(5)SPDY/HTTP2

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