最近大家在使用百度、谷歌或淘寶的時候，是不是注意瀏覽器左上角已經全部出現了一把綠色鎖，這把鎖表明該網站已經使用了 HTTPS 進行保護。仔細觀察，會發現這些網站已經全站使用 HTTPS。同時，iOS 9 系統預設把所有的 http 請求都改為 HTTPS 請求。隨著網際網路的發展，現代網際網路正在逐漸進入全站 HTTPS 時代。

因此有開發同學會問：

全站 HTTPS 能夠帶來怎樣的優勢?HTTPS 的原理又是什麼?同時，阻礙 HTTPS 普及的困難是什麼?

為了解答大家的困惑，騰訊TEG架構平臺部靜態加速組高階工程師劉強，為大家綜合參考多種資料並經過實踐驗證，探究 HTTPS 的基礎原理，分析基本的 HTTPS 通訊過程，迎接全站 HTTPS 的來臨。

1.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 頁面進行太多的改造。

2.TLS/SSL 原理

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

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

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

;          對稱加密，常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的金鑰可以用於資訊的加密和解密，掌握金鑰才能獲取資訊，能夠防止資訊竊聽，通訊方式是1對1;非對稱加密，即常見的 RSA 演算法，還包括 ECC、DH 等演算法，演算法特點是，金鑰成對出現（一個公鑰一個私鑰，1對1的關係），一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的資訊只能私鑰解開，私鑰加密的資訊只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密資訊，只能和掌握私鑰的伺服器進行加密通訊，伺服器可以實現1對多的通訊，客戶端也可以用來驗證掌握私鑰的伺服器身份。

在資訊傳輸過程中，雜湊函式不能單獨實現資訊防篡改，因為明文傳輸，中間人可以修改資訊之後重新計算資訊摘要，因此需要對傳輸的資訊以及資訊摘要進行加密;對稱加密的優勢是資訊傳輸1對1，需要共享相同的密碼，密碼的安全是保證資訊保安的基礎，伺服器和 N 個客戶端通訊，需要維持 N 個密碼記錄，且缺少修改密碼的機制;非對稱加密的特點是資訊傳輸1對多，伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通訊，但伺服器發出的資訊能夠被所有的客戶端解密，且該演算法的計算複雜，加密速度慢。

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

3.PKI 體系 3.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 可以進行資訊的竊聽、篡改等操作。

另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。

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

3.2 身份驗證-CA 和證書

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

基本的原理為，CA 負責稽核資訊，然後對關鍵資訊利用私鑰進行”簽名”，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 檔案和 OCSP。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 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書;

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

 

看到這裡大家就有一些瞭解了，感興趣的可以繼續往下看。

 

3.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.不同證書鏈的層級不一定相同，可能二級、三級或四級證書鏈。

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

3.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 地址的，對於吊銷證書會是一件非常麻煩的事情。

4.TLS/SSL握手過程

4.1握手與金鑰協商過程

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

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 就屬於擴充套件欄位，後續單獨討論該欄位作用。

2.server_hello+server_certificate+sever_hello_done

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

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

(c) server_hello_done，通知客戶端 server_hello 資訊傳送結束;

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)

(c) change_cipher_spec，客戶端通知伺服器後續的通訊都採用協商的通訊金鑰和加密演算法進行加密通訊;

(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，驗證資料和金鑰正確性;

(c) change_cipher_spec, 驗證通過之後，伺服器同樣傳送 change_cipher_spec 以告知客戶端後續的通訊都採用協商的金鑰與演算法進行加密通訊;

(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 等，協商細節略有不同，總體相似;

(c) sever key exchange 的作用是 server certificate 沒有攜帶足夠的資訊時，傳送給客戶端以計算 pre-master，如基於 DH 的證書，公鑰不被證書中包含，需要單獨傳送;

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

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

4.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 中攜帶記錄的資訊，傳送給伺服器;

(c) 伺服器根據收到的 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 中攜帶加密資訊，一起傳送給伺服器;

(c) 伺服器解密 sesssion_ticket 資料，如果能夠解密失敗，則按照正常的握手過程進行;

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

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

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

4.3 重建連線

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

1.伺服器重建連線

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

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

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

(c) 伺服器端返回 hello_request 資訊;

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

2.客戶端重建連線

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

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

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

(c) 伺服器端收到 client_hello 資訊之後無法立即識別出該資訊非應用資料，因此會提交給下一步處理，處理完之後會返回通知該資訊為要求重建連線;

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

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

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

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

4.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;

(c) Master secret 結合 random client 和 random server 兩個隨機數通過迭代計算得到 Key material;

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

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

(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 元素解密;

(c) 雙向通訊的不同方向使用的金鑰不同，破解通訊至少需要破解兩次;

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

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

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

4.4 資料加密通訊過程

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

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

(c) 使用協商的壓縮演算法壓縮資料;

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

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

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

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

4.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 會說明建立連線失敗的原因即告警型別，對於定位問題非常重要。

5.HTTPS 效能與優化

5.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 接入的主要難題。

5.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 的效能，提高下載速度等。

來源：騰訊bugly