HTTPS原理探討（二）

TLS/SSL握手過程

握手與密鑰協商過程

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

---

會話緩存握手過程

爲了加快創建握手的速度，減小協議帶來的性能下降和資源消耗(具體分析在後文)，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用於數據的完整性校驗；

---

數據加密通訊過程

(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 ticket是擴展協議部分，存在該字段說明協議支持sesssion ticket，不然不支持，存在且值爲空，說明以前未創建並緩存鏈接，存在且值不爲空，說明有緩存鏈接。
4.server_hello
根據TLS version字段可以推測出服務器支持的協議的最高版本，版本不一樣可能形成握手失敗；
基於cipher_suite信息判斷出服務器優先支持的加密協議；
5.ceritficate
服務器配置並返回的證書鏈，根據證書信息並於服務器配置文件對比，判斷請求與指望是否一致，若是不一致，是否返回的默認證書。
6.alert
告警信息alert會說明創建鏈接失敗的緣由即告警類型，對於定位問題很是重要。

---

HTTPS性能與優化

HTTPS性能損耗

前文討論了HTTPS原理與優點：身份驗證、信息加密與完整性校驗等，且未對TCP和HTTP協議作任何修改。但經過增長新協議以實現更安全的通訊必然須要付出代價，HTTPS協議的性能損耗主要體現以下：
1.增長延時
分析前面的握手過程，一次完整的握手至少須要兩端依次來回兩次通訊，至少增長延時2RTT，利用會話緩存從而複用鏈接，延時也至少1RTT。
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接入的解決方案之一。
5.SPDY/HTTP2
前面的方法分別從減小傳輸延時和單機負載的方法提升HTTPS接入性能，可是方法都基於不改變HTTP協議的基礎上提出的優化方法，SPDY/HTTP2利用TLS/SSL帶來的優點，經過修改協議的方法來提高HTTPS的性能，提升下載速度等。

參考連接：
http://segmentfault.com/a/119...
http://www.fenesky.com/blog/2...
https://technet.microsoft.com...
https://www.ietf.org/rfc/rfc2...