HTTPS如何優化？

由裸資料傳輸的 HTTP 協議轉成加密資料傳輸的 HTTPS 協議，給應用資料套了個「保護傘」，提高安全性的同時也帶來了性能消耗，

因為 HTTPS 相比 HTTP 協議多一個 TLS 協議握手程序，目的是為了通過非對稱加密握手協商或者交換出對稱加密密鑰，這個程序最長可以花費掉 2 RTT，接著后續傳輸的應用資料都得使用對稱加密密鑰來加密/解密，

為了資料的安全性，我們不得不使用 HTTPS 協議，至今大部分網址都已從 HTTP 遷移至 HTTPS 協議，因此針對 HTTPS 的優化是非常重要的，

這次，就從多個角度來優化 HTTPS，

分析性能損耗

既然要對 HTTPS 優化，那得清楚哪些步驟會產生性能消耗，再對癥下藥，

產生性能消耗的兩個環節：

• 第一個環節， TLS 協議握手程序；

• 第二個環節，握手后的對稱加密報文傳輸，

對于第二環節，現在主流的對稱加密演算法 AES、ChaCha20 性能都是不錯的，而且一些 CPU 廠商還針對它們做了硬體級別的優化，因此這個環節的性能消耗可以說非常地小，

而第一個環節，TLS 協議握手程序不僅增加了網路延時（最長可以花費掉 2 RTT），而且握手程序中的一些步驟也會產生性能損耗，比如：

• 對于 ECDHE 密鑰協商演算法，握手程序中會客戶端和服務端都需要臨時生成橢圓曲線公私鑰；

• 客戶端驗證證書時，會訪問 CA 獲取 CRL 或者 OCSP，目的是驗證服務器的證書是否有被吊銷；

• 雙方計算 Pre-Master，也就是會話密鑰；

為了大家更清楚這些步驟在 TLS 協議握手的哪一個階段，我畫出了這幅圖：

硬體優化

玩游戲時，如果我們怎么都戰勝不了對方，那么有一個最有效、最快的方式來變強，那就是「充錢」，如果還是不行，那說明你充的錢還不夠多，

對于計算機里也是一樣，軟體都是跑在物理硬體上，硬體越牛逼，軟體跑的也越快，所以如果要優化 HTTPS 優化，最直接的方式就是花錢買性能引數更牛逼的硬體，

但是花錢也要花對方向，HTTPS 協議是計算密集型，而不是 I/O 密集型，所以不能把錢花在網卡、硬碟等地方，應該花在 CPU 上，

一個好的 CPU，可以提高計算性能，因為 HTTPS 連接程序中就有大量需要計算密鑰的程序，所以這樣可以加速 TLS 握手程序，

另外，如果可以，應該選擇可以支持 AES-NI 特性的 CPU，因為這種款式的 CPU 能在指令級別優化了 AES 演算法，這樣便加速了資料的加解密傳輸程序，

如果你的服務器是 Linux 系統，那么你可以使用下面這行命令查看 CPU 是否支持 AES-NI 指令集：

如果我們的 CPU 支持 AES-NI 特性，那么對于對稱加密的演算法應該選擇 AES 演算法，否則可以選擇 ChaCha20 對稱加密演算法，因為 ChaCha20 演算法的運算指令相比 AES 演算法會對 CPU 更友好一點，

軟體優化

如果公司預算充足對于新的服務器是可以考慮購買更好的 CPU，但是對于已經在使用的服務器，硬體優化的方式可能就不太適合了，于是就要從軟體的方向來優化了，

軟體的優化方向可以分層兩種，一個是軟體升級，一個是協議優化，

先說第一個軟體升級，軟體升級就是將正在使用的軟體升級到最新版本，因為最新版本不僅提供了最新的特性，也優化了以前軟體的問題或性能，比如：

• 將 Linux 內核從 2.x 升級到 4.x；

• 將 OpenSSL 從 1.0.1 升級到 1.1.1；

• …

看似簡單的軟體升級，對于有成百上千服務器的公司來說，軟體升級也跟硬體升級同樣是一個棘手的問題，因為要實行軟體升級，會花費時間和人力，同時也存在一定的風險，也可能會影響正常的線上服務，

既然如此，我們把目光放到協議優化，也就是在現有的環節下，通過較小的改動，來進行優化，

協議優化

協議的優化就是對「密鑰交換程序」進行優化，

密鑰交換演算法優化

TLS 1.2 版本如果使用的是 RSA 密鑰交換演算法，那么需要 4 次握手，也就是要花費 2 RTT，才可以進行應用資料的傳輸，而且 RSA 密鑰交換演算法不具備前向安全性，

總之使用 RSA 密鑰交換演算法的 TLS 握手程序，不僅慢，而且安全性也不高，

因此如果可以，盡量選用 ECDHE 密鑰交換演算法替換 RSA 演算法，因為該演算法由于支持「False Start」，它是“搶跑”的意思，客戶端可以在 TLS 協議的第 3 次握手后，第 4 次握手前，發送加密的應用資料，以此將 TLS 握手的訊息往返由 2 RTT 減少到 1 RTT，而且安全性也高，具備前向安全性，

ECDHE 演算法是基于橢圓曲線實作的，不同的橢圓曲線性能也不同，應該盡量選擇 x25519 曲線，該曲線是目前最快的橢圓曲線，

比如在 Nginx 上，可以使用 ssl_ecdh_curve 指令配置想使用的橢圓曲線，把優先使用的放在前面：

對于對稱加密演算法方面，如果對安全性不是特別高的要求，可以選用 AES_128_GCM，它比 AES_256_GCM 快一些，因為密鑰的長度短一些，

比如在 Nginx 上，可以使用 ssl_ciphers 指令配置想使用的非對稱加密演算法和對稱加密演算法，也就是密鑰套件，而且把性能最快最安全的演算法放在最前面：

TLS 升級

當然，如果可以，直接把 TLS 1.2 升級成 TLS 1.3，TLS 1.3 大幅度簡化了握手的步驟，完成 TLS 握手只要 1 RTT，而且安全性更高，

在 TLS 1.2 的握手中，一般是需要 4 次握手，先要通過 Client Hello （第 1 次握手）和 Server Hello（第 2 次握手） 訊息協商出后續使用的加密演算法，再互相交換公鑰（第 3 和 第 4 次握手），然后計算出最終的會話密鑰，下圖的左邊部分就是 TLS 1.2 的握手程序：

上圖的右邊部分就是 TLS 1.3 的握手程序，可以發現 TLS 1.3 把 Hello 和公鑰交換這兩個訊息合并成了一個訊息，于是這樣就減少到只需 1 RTT 就能完成 TLS 握手，

怎么合并的呢？具體的做法是，客戶端在 Client Hello 訊息里帶上了支持的橢圓曲線，以及這些橢圓曲線對應的公鑰，

服務端收到后，選定一個橢圓曲線等引數，然后回傳訊息時，帶上服務端這邊的公鑰，經過這 1 個 RTT，雙方手上已經有生成會話密鑰的材料了，于是客戶端計算出會話密鑰，就可以進行應用資料的加密傳輸了，

而且，TLS1.3 對密碼套件進行“減肥”了，對于密鑰交換演算法，廢除了不支持前向安全性的 RSA 和 DH 演算法，只支持 ECDHE 演算法，

對于對稱加密和簽名演算法，只支持目前最安全的幾個密碼套件，比如 openssl 中僅支持下面 5 種密碼套件：

• TLS_AES_256_GCM_SHA384

• TLS_CHACHA20_POLY1305_SHA256

• TLS_AES_128_GCM_SHA256

• TLS_AES_128_CCM_8_SHA256

• TLS_AES_128_CCM_SHA256

之所以 TLS1.3 僅支持這么少的密碼套件，是因為 TLS1.2 由于支持各種古老且不安全的密碼套件，中間人可以利用降級攻擊，偽造客戶端的 Client Hello 訊息，替換客戶端支持的密碼套件為一些不安全的密碼套件，使得服務器被迫使用這個密碼套件進行 HTTPS 連接，從而破解密文，

證書優化

為了驗證的服務器的身份，服務器會在 TSL 握手程序中，把自己的證書發給客戶端，以此證明自己身份是可信的，

對于證書的優化，可以有兩個方向：

• 一個是證書傳輸，

• 一個是證書驗證；

證書傳輸優化

要讓證書更便于傳輸，那必然是減少證書的大小，這樣可以節約帶寬，也能減少客戶端的運算量，所以，對于服務器的證書應該選擇 橢圓曲線（ECDSA）證書，而不是 RSA 證書，因為在相同安全強度下， ECC 密鑰長度比 RSA 短的多， 

證書驗證優化

客戶端在驗證證書時，是個復雜的程序，會走證書鏈逐級驗證，驗證的程序不僅需要「用 CA 公鑰解密證書」以及「用簽名演算法驗證證書的完整性」，而且為了知道證書是否被 CA 吊銷，客戶端有時還會再去訪問 CA， 下載 CRL 或者 OCSP 資料，以此確認證書的有效性，

這個訪問程序是 HTTP 訪問，因此又會產生一系列網路通信的開銷，如 DNS 查詢、建立連接、收發資料等，

CRL

CRL 稱為證書吊銷串列（Certificate Revocation List），這個串列是由 CA 定期更新，串列內容都是被撤銷信任的證書序號，如果服務器的證書在此串列，就認為證書已經失效，不在的話，則認為證書是有效的，

但是 CRL 存在兩個問題：

• 第一個問題，由于 CRL 串列是由 CA 維護的，定期更新，如果一個證書剛被吊銷后，客戶端在更新 CRL 之前還是會信任這個證書，實時性較差；

• 第二個問題，隨著吊銷證書的增多，串列會越來越大，下載的速度就會越慢，下載完客戶端還得遍歷這么大的串列，那么就會導致客戶端在校驗證書這一環節的延時很大，進而拖慢了 HTTPS 連接，

OCSP

因此，現在基本都是使用 OCSP ，名為在線證書狀態協議（Online Certificate Status Protocol）來查詢證書的有效性，它的作業方式是向 CA 發送查詢請求，讓 CA 回傳證書的有效狀態，

不必像 CRL 方式客戶端需要下載大大的串列，還要從串列查詢，同時因為可以實時查詢每一張證書的有效性，解決了 CRL 的實時性問題，

OCSP 需要向 CA 查詢，因此也是要發生網路請求，而且還得看 CA 服務器的“臉色”，如果網路狀態不好，或者 CA 服務器繁忙，也會導致客戶端在校驗證書這一環節的延時變大，

OCSP Stapling

于是為了解決這一個網路開銷，就出現了 OCSP Stapling，其原理是：服務器向 CA 周期性地查詢證書狀態，獲得一個帶有時間戳和簽名的回應結果并快取它，

當有客戶端發起連接請求時，服務器會把這個「回應結果」在 TLS 握手程序中發給客戶端，由于有簽名的存在，服務器無法篡改，因此客戶端就能得知證書是否已被吊銷了，這樣客戶端就不需要再去查詢，

會話復用

TLS 握手的目的就是為了協商出會話密鑰，也就是對稱加密密鑰，那我們如果我們把首次 TLS 握手協商的對稱加密密鑰快取起來，待下次需要建立 HTTPS 連接時，直接「復用」這個密鑰，不就減少 TLS 握手的性能損耗了嗎？

這種方式就是會話復用（TLS session resumption），會話復用分兩種：

• 第一種叫 Session ID；

• 第二種叫 Session Ticket；

Session ID

Session ID 的作業原理是，客戶端和服務器首次 TLS 握手連接后，雙方會在記憶體快取會話密鑰，并用唯一的 Session ID 來標識，Session ID 和會話密鑰相當于 key-value 的關系，

當客戶端再次連接時，hello 訊息里會帶上 Session ID，服務器收到后就會從記憶體找，如果找到就直接用該會話密鑰恢復會話狀態，跳過其余的程序，只用一個訊息往返就可以建立安全通信，當然為了安全性，記憶體中的會話密鑰會定期失效，

但是它有兩個缺點：

• 服務器必須保持每一個客戶端的會話密鑰，隨著客戶端的增多，服務器的記憶體壓力也會越大，

• 現在網站服務一般是由多臺服務器通過負載均衡提供服務的，客戶端再次連接不一定會命中上次訪問過的服務器，于是還要走完整的 TLS 握手程序；

Session Ticket

為了解決 Session ID 的問題，就出現了 Session Ticket，服務器不再快取每個客戶端的會話密鑰，而是把快取的作業交給了客戶端，類似于 HTTP 的 Cookie，

客戶端與服務器首次建立連接時，服務器會加密「會話密鑰」作為 Ticket 發給客戶端，交給客戶端快取該 Ticket，

客戶端再次連接服務器時，客戶端會發送 Ticket，服務器解密后就可以獲取上一次的會話密鑰，然后驗證有效期，如果沒問題，就可以恢復會話了，開始加密通信，

對于集群服務器的話，要確保每臺服務器加密 「會話密鑰」的密鑰是一致的，這樣客戶端攜帶 Ticket 訪問任意一臺服務器時，都能恢復會話，

Session ID 和 Session Ticket 都不具備前向安全性，因為一旦加密「會話密鑰」的密鑰被破解或者服務器泄漏「會話密鑰」，前面劫持的通信密文都會被破解，

同時應對重放攻擊也很困難，這里簡單介紹下重放攻擊作業的原理，

假設 Alice 想向 Bob 證明自己的身份，Bob 要求 Alice 的密碼作為身份證明，愛麗絲應盡全力提供（可能是在經過如哈希函式的轉換之后），與此同時，Eve 竊聽了對話并保留了密碼（或哈希），

交換結束后，Eve（冒充 Alice ）連接到 Bob，當被要求提供身份證明時，Eve 發送從 Bob 接受的最后一個會話中讀取的 Alice 的密碼（或哈希），從而授予 Eve 訪問權限，

重放攻擊的危險之處在于，如果中間人截獲了某個客戶端的 Session ID 或 Session Ticket 以及 POST 報文，而一般 POST 請求會改變資料庫的資料，中間人就可以利用此截獲的報文，不斷向服務器發送該報文，這樣就會導致資料庫的資料被中間人改變了，而客戶是不知情的，

避免重放攻擊的方式就是需要對會話密鑰設定一個合理的過期時間，

Pre-shared Key

前面的 Session ID 和 Session Ticket 方式都需要在 1 RTT 才能恢復會話，

而 TLS1.3 更為牛逼，對于重連 TLS1.3 只需要 0 RTT，原理和 Ticket 類似，只不過在重連時，客戶端會把 Ticket 和 HTTP 請求一同發送給服務端，這種方式叫 Pre-shared Key，

同樣的，Pre-shared Key 也有重放攻擊的危險，

如上圖，假設中間人通過某種方式，截獲了客戶端使用會話重用技術的 POST 請求，通常 POST 請求是會改變資料庫的資料，然后中間人就可以把截獲的這個報文發送給服務器，服務器收到后，也認為是合法的，于是就恢復會話，致使資料庫的資料又被更改，但是此時用戶是不知情的，

總結

巨人的肩膀

1. http://www.doc88.com/p-8621583210895.html

2. https://zhuanlan.zhihu.com/p/33685085

3. https://en.wikipedia.org/wiki/Replay_attack

4. https://en.wikipedia.org/wiki/Downgrade_attack

5. https://www.cnblogs.com/racent-Z/p/14011056.html

6. http://www.guoyanbin.com/a-detailed-look-at-rfc-8446-a-k-a-tls-1-3/

7. https://www.thesslstore.com/blog/crl-explained-what-is-a-certificate-revocation-list/