全站 HTTPS 來了(轉載)

轉載:本文爲騰訊Bugly原創文章。

最近你們在使用百度、谷歌或淘寶的時候，是否是注意瀏覽器左上角已經所有出現了一把綠色鎖，這把鎖代表該網站已經使用了 HTTPS 進行保護。仔細觀察，會發現這些網站已經全站使用 HTTPS。同時，iOS 9 系統默認把全部的 http 請求都改成 HTTPS 請求。隨着互聯網的發展，現代互聯網正在逐漸進入全站 HTTPS 時代。

所以有開發同窗在給騰訊Bugly的郵件中問：
全站 HTTPS 可以帶來怎樣的優點？HTTPS 的原理又是什麼？同時，阻礙 HTTPS 普及的困難是什麼？
爲了解答你們的困惑，騰訊Bugly特意邀請到了咱們的高級工程師劉強，爲你們綜合參考多種資料並通過實踐驗證，探究 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，常見的有 MD五、SHA一、SHA256，該類函數特色是函數單向不可逆、對輸入很是敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用於防止信息篡改並驗證數據的完整性；對稱加密，常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰能夠用於信息的加密和解密，掌握密鑰才能獲取信息，可以防止信息竊聽，通訊方式是1對1；非對稱加密，即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特色是，密鑰成對出現，通常稱爲公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。所以掌握公鑰的不一樣客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通訊，服務器能夠實現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 使用具體的流程以下：

1. 服務方 S 向第三方機構CA提交公鑰、組織信息、我的信息(域名)等信息並申請認證；

2. CA 經過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的全部權等；

3. 如信息審覈經過，CA 會向申請者簽發認證文件-證書。

   • 證書包含如下信息：申請者公鑰、申請者的組織信息和我的信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

   • 簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，而後，採用 CA 的私鑰對信息摘要進行加密，密文即簽名；

4. 客戶端 C 向服務器 S 發出請求時，S 返回證書文件；

5. 客戶端 C 讀取證書中的相關的明文信息，採用相同的散列函數計算獲得信息摘要，而後，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，若是一致，則能夠確認證書的合法性，即公鑰合法；

6. 客戶端而後驗證證書相關的域名信息、有效時間等信息；

7. 客戶端會內置信任 CA 的證書信息(包含公鑰)，若是CA不被信任，則找不到對應 CA 的證書，證書也會被斷定非法。

在這個過程注意幾點：

1. 申請證書不須要提供私鑰，確保私鑰永遠只能服務器掌握；

2. 證書的合法性仍然依賴於非對稱加密算法，證書主要是增長了服務器信息以及簽名；

3. 內置 CA 對應的證書稱爲根證書，頒發者和使用者相同，本身爲本身簽名，即自簽名證書；

4. 證書=公鑰+申請者與頒發者信息+簽名；

3.3 證書鏈

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

1. 服務器證書 server.pem 的簽發者爲中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實爲本身簽發的有效證書；

2. 中間證書 inter.pem 的簽發 CA 爲 root，root 根據證書 root.pem 驗證 inter.pem 爲本身簽發的合法證書；

3. 客戶端內置信任 CA 的 root.pem 證書，所以服務器證書 server.pem 的被信任。

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

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

1. 減小根證書結構的管理工做量，能夠更高效的進行證書的審覈與簽發；

2. 根證書通常內置在客戶端中，私鑰通常離線存儲，一旦私鑰泄露，則吊銷過程很是困難，沒法及時補救；

3. 中間證書結構的私鑰泄露，則能夠快速在線吊銷，並從新爲用戶簽發新的證書；

4. 證書鏈四級之內通常不會對 HTTPS 的性能形成明顯影響。

證書鏈有如下特色：

1. 同一本服務器證書可能存在多條合法的證書鏈。
   由於證書的生成和驗證基礎是公鑰和私鑰對，若是採用相同的公鑰和私鑰生成不一樣的中間證書，針對被簽發者而言，該簽發機構都是合法的 CA，不一樣的是中間證書的簽發機構不一樣；

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

中間證書的簽發機構多是根證書機構也多是另外一箇中間證書機構，因此證書鏈層級不必定相同。

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

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

2. server_certificates, 服務器端配置對應的證書鏈，用於身份驗證與密鑰交換；

3. 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

1. client_key_exchange，合法性驗證經過以後，客戶端計算產生隨機數字 Pre-master，並用證書公鑰加密，發送給服務器；

2. 此時客戶端已經獲取所有的計算協商密鑰須要的信息：兩個明文隨機數 random_C 和 random_S 與本身計算產生的 Pre-master，計算獲得協商密鑰;

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

3. change_cipher_spec，客戶端通知服務器後續的通訊都採用協商的通訊密鑰和加密算法進行加密通訊;

4. encrypted_handshake_message，結合以前全部通訊參數的 hash 值與其它相關信息生成一段數據，採用協商密鑰 session secret 與算法進行加密，而後發送給服務器用於數據與握手驗證;

5. change_cipher_spec+encrypted_handshake_message

1. 服務器用私鑰解密加密的 Pre-master 數據，基於以前交換的兩個明文隨機數 random_C 和 random_S，計算獲得協商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master)；

2. 計算以前全部接收信息的 hash 值，而後解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性；

3. change_cipher_spec, 驗證經過以後，服務器一樣發送 change_cipher_spec 以告知客戶端後續的通訊都採用協商的密鑰與算法進行加密通訊；

4. encrypted_handshake_message, 服務器也結合全部當前的通訊參數信息生成一段數據並採用協商密鑰 session secret 與算法加密併發送到客戶端；

6. 握手結束

客戶端計算全部接收信息的 hash 值，並採用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證經過則握手完成；

7. 加密通訊

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

注意：

1. 服務器也能夠要求驗證客戶端，即雙向認證，能夠在過程2要發送 client_certificate_request 信息，客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是採用client的私鑰加密的一段基於已經協商的通訊信息獲得數據，服務器能夠採用對應的公鑰解密並驗證；

2. 根據使用的密鑰交換算法的不一樣，如 ECC 等，協商細節略有不一樣，整體類似；

3. sever key exchange 的做用是 server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基於 DH 的證書，公鑰不被證書中包含，須要單獨發送；

4. change cipher spec 實際可用於通知對端改版當前使用的加密通訊方式，當前沒有深刻解析；

5. 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

1. 若是客戶端和服務器之間曾經創建了鏈接，服務器會在握手成功後返回 session ID，並保存對應的通訊參數在服務器中；

2. 若是客戶端再次須要和該服務器創建鏈接，則在 client_hello 中 session ID 中攜帶記錄的信息，發送給服務器；

3. 服務器根據收到的 session ID 檢索緩存記錄，若是沒有檢索到貨緩存過時，則按照正常的握手過程進行；

4. 若是檢索到對應的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息做用相似，encrypted_handshake_message 是到當前的通訊參數與 master_secret的hash 值；

5. 若是客戶端可以驗證經過服務器加密數據，則客戶端一樣發送 change_cipher_spec 與 encrypted_handshake_message 信息；

6. 服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊。

2. 會話記錄 session ticket

1. 若是客戶端和服務器之間曾經創建了鏈接，服務器會在 new_session_ticket 數據中攜帶加密的 session_ticket 信息，客戶端保存；

2. 若是客戶端再次須要和該服務器創建鏈接，則在 client_hello 中擴展字段 session_ticket 中攜帶加密信息，一塊兒發送給服務器；

3. 服務器解密 sesssion_ticket 數據，若是可以解密失敗，則按照正常的握手過程進行；

4. 若是解密成功，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息做用與 session ID 中相似；

5. 若是客戶端可以驗證經過服務器加密數據，則客戶端一樣發送 change_cipher_spec與encrypted_handshake_message 信息；

6. 服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊。

4.3 重建鏈接

重建鏈接 renegotiation 即放棄正在使用的 TLS 鏈接，重新進行身份認證和密鑰協商的過程，特色是不須要斷開當前的數據傳輸就能夠從新身份認證、更新密鑰或算法，所以服務器端存儲和緩存的信息均可以保持。客戶端和服務器都可以發起重建鏈接的過程，當前 windows 2000 & XP 與 SSL 2.0不支持。

1. 服務器重建鏈接

服務器端重建鏈接通常狀況是客戶端訪問受保護的數據時發生。基本過程以下：

(a) 客戶端和服務器之間創建了有效 TLS 鏈接並通訊；
(b) 客戶端訪問受保護的信息；
(c) 服務器端返回 hello_request 信息;
(d) 客戶端收到 hello_request 信息以後發送 client_hello 信息，開始從新創建鏈接。

2. 客戶端重建鏈接

客戶端重建鏈接通常是爲了更新通訊密鑰。

1. 客戶端和服務器之間創建了有效 TLS 鏈接並通訊；

2. 客戶端須要更新密鑰，主動發出 client_hello 信息；

3. 服務器端收到 client_hello 信息以後沒法當即識別出該信息非應用數據，所以會提交給下一步處理，處理完以後會返回通知該信息爲要求重建鏈接；

4. 在肯定重建鏈接以前，服務器不會當即中止向客戶端發送數據，可能剛好同時或有緩存數據須要發送給客戶端，可是客戶端不會再發送任何信息給服務器；

5. 服務器識別出重建鏈接請求以後，發送 server_hello 信息至客戶端；

6. 客戶端也一樣沒法當即判斷出該信息非應用數據，一樣提交給下一步處理，處理以後會返回通知該信息爲要求重建鏈接；

7. 客戶端和服務器開始新的重建鏈接的過程。

4.4 密鑰計算

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

1.計算 Key

涉及參數 random client 和 random server, Pre-master, Master secret, key material, 計算密鑰時，服務器和客戶端都具備這些基本信息，交換方式在上節中有說明，計算流程以下：

1. 客戶端採用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master；

2. Pre-master 結合 random client 和 random server 兩個隨機數經過 PseudoRandomFunction(PRF)計算獲得 Master secret;

3. 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個元素，列表以下：

1. mac key、encryption key 和 IV 是一組加密元素，分別被客戶端和服務器使用，可是這兩組元素都被兩邊同時獲取；

2. 客戶端使用 client 組元素加密數據，服務器使用 client 元素解密；服務器使用 server 元素加密，client 使用 server 元素解密；

3. 雙向通訊的不一樣方向使用的密鑰不一樣，破解通訊至少須要破解兩次；

4. encryption key 用於對稱加密數據；

5. IV 做爲不少加密算法的初始化向量使用，具體能夠研究對稱加密算法；

6. Mac key 用於數據的完整性校驗；

4.4 數據加密通訊過程

1. 對應用層數據進行分片成合適的 block;

2. 爲分片數據編號，防止重放攻擊；

3. 使用協商的壓縮算法壓縮數據；

4. 計算 MAC 值和壓縮數據組成傳輸數據；

5. 使用 client encryption key 加密數據，發送給服務器 server；

6. 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 的性能，提升下載速度等。