安全超文本傳輸協議（HTTPS）詳解

1、概念與摘要

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

什麼是HTTPS

HTTPS是在HTTP上創建SSL加密層，並對傳輸數據進行加密，是HTTP協議的安全版。HTTPS主要做用是：

（1）對數據進行加密，並創建一個信息安全通道，來保證傳輸過程當中的數據安全;

（2）對網站服務器進行真實身份認證。

什麼是HTTP

HTTP是互聯網上應用最爲普遍的一種網絡協議，是一個客戶端和服務器端請求和應答的標準(TCP)，用於從WWW服務器傳輸超文本到本地瀏覽器的傳輸協議。HTTP是採用明文形式進行數據傳輸，極易被不法份子竊取和篡改。

HTTPS和HTTP的區別是什麼

一、HTTPS是加密傳輸協議，HTTP是名文傳輸協議;

二、 HTTPS標準端口443，HTTP標準端口80;

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

協議層面的區別以下圖：

3、TLS/SSL工做原理

HTTPS協議的主要功能基本都依賴於TLS/SSL協議，TLS/SSL的功能實現主要依賴於三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

散列函數Hash

常見的有 MD五、SHA一、SHA256，該類函數特色是函數單向不可逆、對輸入很是敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用於防止信息篡改並驗證數據的完整性;

在信息傳輸過程當中，散列函數不能單獨實現信息防篡改，由於明文傳輸，中間人能夠修改信息以後從新計算信息摘要，所以須要對傳輸的信息以及信息摘要進行加密;

對稱加密

常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰能夠用於信息的加密和解密，掌握密鑰才能獲取信息，可以防止信息竊聽，通訊方式是1對1;

對稱加密的優點是信息傳輸1對1，須要共享相同的密碼，密碼的安全是保證信息安全的基礎，服務器和 N 個客戶端通訊，須要維持 N 個密碼記錄，且缺乏修改密碼的機制;

非對稱加密

即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特色是，密鑰成對出現，通常稱爲公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。所以掌握公鑰的不一樣客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通訊，服務器能夠實現1對多的通訊，客戶端也能夠用來驗證掌握私鑰的服務器身份。

非對稱加密的特色是信息傳輸1對多，服務器只須要維持一個私鑰就可以和多個客戶端進行加密通訊，但服務器發出的信息可以被全部的客戶端解密，且該算法的計算複雜，加密速度慢。

結合三類算法的特色，TLS的基本工做方式是，客戶端使用非對稱加密與服務器進行通訊，實現身份驗證並協商對稱加密使用的密鑰，而後對稱加密算法採用協商密鑰對信息以及信息摘要進行加密通訊，不一樣的節點之間採用的對稱密鑰不一樣，從而能夠保證信息只能通訊雙方獲取。

4、TLS/SSL握手過程

握手與密鑰協商過程

下圖展示了----基於RSA握手和密鑰交換的客戶端驗證服務器爲示例詳解TLS/SSL握手過程。

(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 用於指明在握手或通訊過程當中的狀態改變或錯誤信息，通常告警信息觸發條件是鏈接關閉，收到不合法的信息，信息解密失敗，用戶取消操做等，收到告警信息以後，通訊會被斷開或者由接收方決定是否斷開鏈接。

會話緩存握手過程

爲了加快創建握手的速度，減小協議帶來的性能下降和資源消耗(具體分析在後文)，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) 服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊。

重建鏈接

重建鏈接 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) 客戶端和服務器開始新的重建鏈接的過程。

密鑰計算

上節提到了兩個明文傳輸的隨機數 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 用於數據的完整性校驗;

（3）.數據加密通訊過程

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

(b) 爲分片數據編號，防止重放攻擊;

(c) 使用協商的壓縮算法壓縮數據;

(d) 計算 MAC 值和壓縮數據組成傳輸數據;

(e) 使用 client encryption key 加密數據，發送給服務器 server;

(f) server 收到數據以後使用 client encrytion key 解密，校驗數據，解壓縮數據，從新組裝。

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

抓包分析

關於抓包再也不詳細分析，按照前面的分析，基本的狀況都可以匹配，根據日常定位問題的過程，我的提些認爲須要注意的地方：

(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性能與優化

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

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接入的解決方案之一。