大型網站的 HTTPS 實踐（三）——基於協議和配置的最佳化

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。

1 前言

上文講到HTTPS對使用者訪問速度的影響。
本文就為大家介紹HTTPS在訪問速度，計算效能，安全等方面基於協議和配置的最佳化。
本文最早發表於百度營運部官方部落格

2 HTTPS訪問速度最佳化

2.1 Tcp fast open

HTTPS和HTTP使用TCP協議進行傳輸，也就意味著必須通過三向交握建立TCP串連，但一個RTT的時間內只傳輸一個syn包是不是太浪費？能不能在syn包發出的同時捎上應用程式層的資料？其實是可以的，這也是tcp fast open的思路，簡稱TFO。具體原理可以參考rfc7413。
遺憾的是TFO需要高版本核心的支援，linux從3.7以後支援TFO，但是目前的windows系統還不支援TFO，所以只能在公司內部伺服器之間發揮作用。

2.2 HSTS

前面提到過將使用者HTTP請求302跳轉到HTTPS，這會有兩個影響：
1. 不安全，302跳轉不僅暴露了使用者的訪問網站，也很容易被中間者支援。
2. 降低訪問速度，302跳轉不僅需要一個RTT，瀏覽器執行跳轉也需要執行時間。
由於302跳轉事實上是由瀏覽器觸發的，伺服器無法完全控制，這個需求導致了HSTS的誕生：
HSTS(HTTP Strict Transport Security)。服務端返回一個HSTS的http header，瀏覽器擷取到HSTS頭部之後，在一段時間內，不管使用者輸入www.baidu.com還是http://www.baidu.com，都會預設將請求內部跳轉成https://www.baidu.com。
Chrome, firefox, ie都支援了HSTS（http://caniuse.com/#feat=stricttransportsecurity）。

2.3 Session resume

Session resume顧名思義就是複用session，實現簡化握手。複用session的好處有兩個：
1. 減少了CPU消耗，因為不需要進行非對稱金鑰交換的計算。
2. 提升訪問速度，不需要進行完全握手階段二，節省了一個RTT和計算耗時。

TLS協議目前提供兩種機制實現session resume，分別介紹一下。

2.3.1 Session cache

Session cache的原理是使用client hello中的session id查詢服務端的session cache,如果服務端有對應的緩衝，則直接使用已有的session資訊提前完成握手，稱為簡化握手。
Session cache有兩個缺點：
1. 需要消耗服務端記憶體來儲存session內容。
2. 目前的開源軟體包括nginx,apache只支援單機多進程間共用快取，不支援多機間分布式緩衝，對於百度或者其他大型互連網公司而言，單機session cache幾乎沒有作用。

Session cache也有一個非常大的優點：
1. session id是TLS協議的標準欄位，市面上的瀏覽器全部都支援session cache。

百度通過對TLS握手協議及伺服器端實現的最佳化，已經支援全域的session cache，能夠明顯提升使用者的訪問速度，節省伺服器計算資源。

2.3.2 Session ticket

上節提到了session cache的兩個缺點，session ticket能夠彌補這些不足。
Session ticket的原理參考RFC4507。簡述如下：
server將session資訊加密成ticket發送給瀏覽器，瀏覽器後續握手請求時會發送ticket，server端如果能成功解密和處理ticket，就能完成簡化握手。
顯然，session ticket的優點是不需要服務端消耗大量資源來儲存session內容。
Session ticket的缺點：
1. session ticket只是TLS協議的一個擴充特性，目前的支援率不是很廣泛，只有60%左右。
2. session ticket需要維護一個全域的key來加解密，需要考慮KEY的安全性和部署效率。

總體來講，session ticket的功能特性明顯優於session cache。希望用戶端實現優先支援session ticket。

2.4 Ocsp stapling

Ocsp全稱線上認證狀態檢查協議(rfc6960)，用來向CA網站查詢認證狀態，比如是否撤銷。通常情況下，瀏覽器使用OCSP協議發起查詢請求，CA返回認證狀態內容，然後瀏覽器接受認證是否可信的狀態。
這個過程非常消耗時間，因為CA網站有可能在國外，網路不穩定，RTT也比較大。那有沒有辦法不直接向CA網站請求OCSP內容呢？ocsp stapling就能實現這個功能。
詳細介紹參考RFC6066第8節。簡述原理就是瀏覽器發起client hello時會攜帶一個certificate status request的擴充，服務端看到這個擴充後將OCSP內容直接返回給瀏覽器，完成認證狀態檢查。
由於瀏覽器不需要直接向CA網站查詢認證狀態，這個功能對訪問速度的提升非常明顯。
Nginx目前已經支援這個ocsp stapling file，只需要配置ocsp stapling file的指令就能開啟這個功能：

ssl_stapling on; ssl_stapling_file ocsp.staple;

2.5 False start

通常情況下，應用程式層資料必須等完全握手全部結束之後才能傳輸。這個其實比較浪費時間，那能不能類似TFO一樣，在完全握手的第二個階段將應用資料一起發出來呢？google提出了false start來實現這個功能。詳細介紹參考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。
簡單概括False start的原理就是在client_key_exchange發出時將應用程式層資料一起發出來，能夠節省一個RTT。
False start依賴於PFS（perfect forward secrecy完美前向加密），而PFS又依賴於DHE金鑰交換系列演算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優先支援ECDHE金鑰交換演算法實現false start。

2.6 使用SPDY或者HTTP2

SPDY是google推出的最佳化HTTP傳輸效率的協議（https://www.chromium.org/spdy），它基本上沿用了HTTP協議的語義,但是通過使用幀控制實現了多個特性，顯著提升了HTTP協議的傳輸效率。
SPDY最大的特性就是多工，能將多個HTTP請求在同一個串連上一起發出去，不像目前的HTTP協議一樣，只能串列地逐個發送請求。Pipeline雖然支援多個請求一起發送，但是接收時依然得按照順序接收，本質上無法解決並發的問題。
HTTP2是IETF 2015年2月份通過的HTTP下一代協議，它以SPDY為原型，經過兩年多的討論和完善最終確定。
本文就不過多介紹SPDY和HTTP2的收益，需要說明兩點：
1. SPDY和HTTP2目前的實現預設使用HTTPS協議。
2. SPDY和HTTP2都支援現有的HTTP語義和API，對WEB應用幾乎是透明的。
Google宣布chrome瀏覽器2016年將放棄SPDY協議，全面支援HTTP2，但是目前國內部分瀏覽器廠商進度非常慢，不僅不支援HTTP2，連SPDY都沒有支援過。
百度服務端和百度手機瀏覽器現在都已經支援SPDY3.1協議。

3 HTTPS計算效能最佳化

3.1 優先使用ECC

ECC橢圓加密算術相比普通的離散對數計算速度效能要強很多。下表是NIST推薦的密鑰長度對照表。

對於RSA演算法來講，目前至少使用2048位以上的密鑰長度才能保證安全性。ECC只需要使用224位長度的密鑰就能實現RSA2048位長度的安全強度。在進行相同的模指數運算時速度顯然要快很多。

3.2 使用最新版的openssl

一般來講，新版的openssl相比老版的計算速度和安全性都會有提升。比如openssl1.0.2採用了intel最新的最佳化成果，橢圓曲線p256的計算效能提升了4倍。(https://eprint.iacr.org/2013/816.pdf)
Openssl 2014年就升級了5次，基本都是為了修複實現上的BUG或者演算法上的漏洞而升級的。所以盡量使用最新版本，避免安全上的風險。

3.3 硬體加速方案

現在比較常用的TLS硬體加速方案主要有兩種：
1. SSL專用加速卡。
2. GPU SSL加速。
上述兩個方案的主流用法都是將硬體插入到伺服器的PCI插槽中，由硬體完成最消耗效能的計算。但這樣的方案有如下缺點：
1. 支援演算法有限。比如不支援ECC，不支援GCM等。
2. 升級成本高。
a) 出現新的密碼編譯演算法或者協議時，硬體加速方案無法及時升級。
b) 出現比較大的安全性漏洞時，部分硬體方案在無法在短期內升級解決。比如2014年暴露的heartbleed漏洞。
3. 無法充分利用硬體加速效能。硬體加速程式一般都運行在核心態，計算結果傳遞到應用程式層需要IO和記憶體拷貝開銷，即使硬體計算效能非常好，上層的同步等待和IO開銷也會導致整體效能達不到預期，無法充分利用硬體加速卡的計算能力。
4. 維護性差。硬體驅動及應用程式層API大部分是由安全廠家提供，出現問題後還需要廠家跟進。使用者無法掌握核心代碼，比較被動。不像開源的openssl，不管演算法還是協議，使用者都能掌握。

3.4 TLS遠程代理計算

也正是因為上述原因，百度實現了專用的SSL硬體加速叢集。基本思路是：
1. 最佳化TLS協議棧，剝離最消耗CPU資源的計算，主要有如下部分：
a) RSA中的加解密計算。
b) ECC演算法中的公私密金鑰產生。
c) ECC演算法中的共用密鑰產生。
2. 最佳化硬體計算部分。硬體計算不涉及協議及狀態互動，只需要處理大數運算。
3. Web server到TLS計算叢集之間的任務是非同步。即web server將待計算內容發送給加速叢集後，依然可以繼續處理其他請求，整個過程是非同步非阻塞的。

4 HTTPS安全配置

4.1 協議版本選擇

SSL2.0早就被證明是不安全的協議了，統計發現目前已經沒有用戶端支援SSL2.0，所以可以放心地在服務端禁用SSL2.0協議。
2014年爆發了POODLE攻擊，SSL3.0因此被證明是不安全的。但是統計發現依然有0.5%的流量只支援SSL3.0。所以只能有選擇地支援SSL3.0。
TLS1.1及1.2目前為止沒有發現安全性漏洞，建議優先支援。

4.2 加密套件選擇

加密套件包含四個部分：
1. 非對稱金鑰交換演算法。建議優先使用ECDHE，禁用DHE，次優先選擇RSA。
2. 認證簽名演算法。由於部分瀏覽器及作業系統不支援ECDSA簽名，目前預設都是使用RSA簽名，其中SHA1簽名已經不再安全，chrome及微軟2016年開始不再支援SHA1簽名的認證(http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。
3. 對稱加解密演算法。優先使用AES-GCM演算法，針對1.0以上協議禁用RC4（ rfc7465）。
4. 內容一致性校正演算法。Md5和sha1都已經不安全，建議使用sha2以上的安全雜湊函數。

4.3 HTTPS防攻擊

4.3.1 防止協議降級攻擊

降級攻擊一般包括兩種：加密套件降級攻擊(cipher suite rollback)和協議降級攻擊（version roll back）。降級攻擊的原理就是攻擊者偽造或者修改client hello訊息，使得用戶端和伺服器之間使用比較弱的加密套件或者協議完成通訊。
為了應對降級攻擊，現在server端和瀏覽器之間都實現了SCSV功能，原理參考https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。
一句話解釋就是如果用戶端想要降級，必鬚髮送TLS_SCSV的訊號，伺服器如果看到TLS_SCSV，就不會接受比服務端最高協議版本低的協議。

4.3.2 防止重新協商攻擊

重新協商（tls renegotiation）分為兩種：加密套件重協商(cipher suite renegotiation)和協議重協商（protocol renegotiation）。
重新協商會有兩個隱患：
1， 重協商後使用弱的安全演算法。這樣的後果就是傳輸內容很容易泄露。
2， 重協商過程中不斷髮起完全握手請求，觸發服務端進行高強度計算並引發服務拒絕。
對於重協商，最直接的保護手段就是禁止用戶端主動重協商，當然出於特殊情境的需求，應該允許服務端主動發起重協商。

5 結束語

HTTPS的實踐和最佳化涉及到了非常多的知識點，由於篇幅關係，本文對很多最佳化策略只是簡單介紹了一下.如果想要瞭解協議背後的原理，還是需要詳細閱讀TLS協議及PKI知識。對於大型網站來說，如果希望做到極致，HTTPS的部署需要結合產品和基礎設施的架構來進行詳細的考慮，比起部署支援HTTPS的接入和對它的最佳化，在產品和營運層面上花費的功夫會更多。本系列的下一篇文章將進一步進行介紹。