HTTPS優化與證書

阿新 • • 發佈：2018-11-02

1、HTTPS效能優化

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

1.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 的效能，提高下載速度等。

1.3 來源JD老司機HTTPS優化指南

1.3.1 優化1：TLS Record Size 動態調整

TLS Record 協議工作在表示層，在傳輸層和應用層之間提供諸如資料封包，加解密，HMAC 校驗等功能，如下圖:

Nginx 在建立 TLS 連線時會為每個連線分配 Buffer 用於傳送原資料（TLS Record Size，預設16KB），當服務端傳送資料時，資料會被切分成 16KB 的多個塊，每個塊用 MAC 簽名，加上協議的元資料以及被加密後的原資料形成一個 TLS Record 結構傳送到客戶端，在客戶端只有當協議棧接收到完整的 TLS Record 時才能夠解密驗證，才會嚮應用層提交。

由於 16KB 的包大小以及丟包等因素的影響，相對於 TCP，HTTPS 的 TTFB( Time To First Byte ) 延時較大。

TTFB 是判斷網站效能的重要指標，主流瀏覽器都是邊下載邊解析渲染的，延時較大最直觀的影響就是終端使用者在瀏覽器端看到內容的速度較慢。

當然 TLS Record Size 也不能一味地變小，比如當它等於 MSS 時，變小就會有較大的頭部負擔，導致整體吞吐量下降。

我們當前使用的是 TLS Record Size動態調整演算法，隨著 CWND 從 Initcwnd 增長到 16K，在延時和吞吐量之間達到相對平衡。

實現思路方式: 開發動態調整工具。

1.3.2 優化2: False Start

通過啟用 False Start，客戶端可以在 Change Cipher Spec 和 Finished 報文後立即傳送應用資料，使得原本需要兩次 RTT 的完全握手變更為一次 RTT。

國內南北網路的平均延時是 50ms，這也就意味著每一個地處南方的使用者訪問地處北方的站點，人均可節省 50ms，效果顯著。

根據 RFC7918 文件，只有使用具有前向安全的祕鑰交換演算法以及足夠強度的對稱加解密演算法時 False Start 才會啟動。

需要注意的是，Chrome 瀏覽器為了解決一些特殊 SSL 服務如 SSL Terminator 硬體裝置的不相容性，要求只有和支援 NPN/ALPN 的服務端通訊才會開啟 False Start。

NPN 隨著 SPDY 被 HTTP/2 代替已被 Chrome 移除，而 ALPN 只在 Openssl-1.0.2 後才開始支援，加之 Openssl 新版本的 Bug 修復以及效能優化，所以如果有條件建議在服務端部署較新版本的 Openssl。

實現思路與方式:

Nginx配置如下:

ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:!NULL:!aNULL:!MD5:!ADH:!RC4;

參考資料: https://segmentfault.com/a/1190000004003319

1.3.3 優化3: OCSP Stapling

OCSP 設計之初是 CRL(Certificate Revocation List) 的替代品，希望通過線上實時的網路互動檢查證書吊銷狀態，但是這個功能有點雞肋：

暴露使用者隱私，Https 旨在提高安全性和保護隱私，OCSP 顯得有點背道而馳
OCSP Responder 基本在國外，而且服務能力未知，假設訪問 OCSP Responder 的延時很大，或者是客戶端和 OCSP Responder 的鏈路主動或被動地斷開，客戶端無法很好地確定是否應該接受證書。

OCSP Stapling 通過服務端對 OCSP 結果的預取並把結果隨著證書一起發給客戶端，從而繞過客戶端的線上驗證過程，可以很好地解決上邊兩個問題。

我們在自己的網站中都應該配置使用 OCSP Stapling，但是需要注意的是 OCSP Stapling 也並非完全能起到檢查證書吊銷的作用，以至於像 Chrome 瀏覽器就已經完全不做證書吊銷檢查了。

實現思路與方式:

Nginx實現配置:

ssl_stapling on;
ssl_stapling_verify on;
resolver 223.5.5.5 223.6.6.6 valid=300s;
resolver_timeout 5s;

參考資料: http://www.jianshu.com/p/638033161329

1.3.4 優化4: HSTS

HSTS（HTTP Strict Transport Security）通過在 HTTPS Response Header 中攜帶 Strict-Transport-Security 來告知瀏覽器：以後請直接通過 HTTPS 訪問我，當第二次使用者在瀏覽器端訪問 HTTP 站點，瀏覽器會在內部做 307 重定向，直接通過 HTTPS 訪問。如下圖：

通過 HSTS 能有效地避免 SSL 剝離攻擊，並能減少 2 個 RTT，強烈建議配置使用。但同時也需關注首次訪問的中間人攻擊，以及準備回滾措施以防 HTTPS 回滾。

實現思路與方式:

Nginx實現:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Frame-Options "DENY";

參考資料: http://www.ttlsa.com/nginx/http-hsts-nginx/, http://www.ttlsa.com/web/hsts-for-nginx-apache-lighttpd/

1.3.5 優化5: 會話複用

常見的會話複用有 Session ID 和 Session Ticket 兩種形式，其中 Session ID 是 TLS 協議的標準欄位，而 Ticket 是擴充套件欄位，根據相關統計，Ticket 的客戶端支援率只有 40% 左右。

通過會話複用，把完全握手變更為簡單握手，避免最耗時的祕鑰協商階段，能顯著提升效能，如下圖，客戶端在發起連線時攜帶上一次完全握手時服務端返回的 SessionID，服務端收到後在記憶體中查詢快取的會話資訊並恢復加密通訊。

但是原生 Nginx 只實現了單機版本的會話複用（SSL_SESSION_CACHE 關鍵字），而當前我們都習慣以叢集方式部署 Nginx 來達到高可用，所以我們通過新增 Nginx 模組以及對 Nginx 原始碼的少量改造，支援分散式會話複用，如下圖，無論請求落到哪一臺 Nginx 機器，都可以複用已快取的會話資訊。

該 Nginx 模組（ngx_ssl_session_cache_module）

已經開源，支援 Redis 和 Memcached 兩種分散式快取系統，且對 Openssl 沒有任何程式碼依賴，歡迎使用，詳見：

傳送門:https://github.com/hzarch/ngx_ssl_session_cache_module.git

實現思路與方式:

簡單的Nginx實現:

ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;

1.3.6 優化6: 雙證書

256 位 ECC 祕鑰加密強度等同於 3072 位 RSA 祕鑰水平且效能更高，而且祕鑰更短意味著更少的儲存空間，更低的頻寬佔用，所以對於有條件的企業建議開啟 ECC & RSA 雙證書支援。

對比 ECDHE_RSA、ECDHE_ECDSA 祕鑰交換認證演算法所需的 RSA_SIGN、ECDSA_SIGN 演算法，以下是我們在普通工作站上通過 OPENSSL SPEED 測試的效能資料，可以明顯看到 ECDSA_SIGN 效能提升。

實現思路與方式:

參考資料: https://www.zeroling.com/nginx-kai-qi-https-shuang-zheng-shu-zhi-nan/

1.3.7 優化7: 對稱加密優化

AES-GCM 是目前常用的分組加密演算法，缺點是效能低以及移動端耗電量大，所以谷歌在 2014 年推出了一種新的流式加密演算法 CHACHA20-POLY1350，在 ARM 平臺上效能是 AES-GCM 的 3-4 倍。

Intel 從 Westmere 處理器開始支援一種新的 x86 指令擴充套件集 AES-NI，AES-NI 能從硬體上加速 AES 的效能，在支援 AES-NI 指令集的主機上實測 AES-GCM 效能是 CHACHA20 的 5 倍左右。

原先我們為權衡相容性和安全性，所以參考 Mozilla 的推薦
（https://wiki.mozilla.org/Security/Server_Side_TLS）

預設採用中檔配置，該配置假設客戶端不支援 AES-NI，所以 CHACHA20 優先於 AES-GCM，然而隨著底層技術的發展，移動端從 ARMV8-A 架構開始逐漸支援 AES 指令集。

像常用的 IPhone 5S，Galaxy Note 4(Exynos)，紅米 2，錘子 T2，榮耀 5X 等都是基於的 ARMV8 架構，考慮到當前網際網路企業的使用者都以年輕群體為主，所以我們改變策略優先使用 AES-GCM。

實現思路與方式:

對稱加密是有客戶端發起，所以對於BS架構，暫無配置資料。

1.3.8 優化8: HTTP/2

HTTP/2 是 HTTP/1.1 在 1999 年釋出後的首次更新，HTTP/2 帶來了諸如多路複用、頭部壓縮、二進位制分幀等特性，能大幅提升 Web 效能。

使用時可以讓客戶端選擇或通過 NPN/ALPN 動態協商是採用 HTTP/1.X over TLS 還是 HTTP/2 over TLS，而且後端服務無需修改程式碼進行適配，具有比較大的靈活性。

但是也需要注意HTTP/2 並不是萬能的解藥，使用時需對網站本身的情況做充分評估，需規避諸如為HTTP/1.X 調優而提出的域名雜湊等問題。

1.3.9 優化9: 加速卡

以上所有的優化都是軟加速範疇，主要目的是減少 RTT，但是對於無法避免的完全握手，服務端還是會進行大量的加解密運算，以 ECDHE_RSA 為例，像 RSA_Sign 函式在 Intel E5-2650 V2 主機上每秒只能執行 1.2W 次左右，而此時 24 個核已全是滿載狀態。

CPU 向來都不適合處理大規模的浮點運算，解決這類問題價效比最高的方式無疑是採用硬體加速卡（GPU 就是其中一種），通過把加解密運算轉移到加速卡來替換 Openssl 的加解密處理。

加速卡安裝在主機的 PCIE 插槽內，受限於主機 PCIE 插槽數量，支援線性擴容，根據加速卡型別不同，像 RSA_Sign 計算效能在單卡狀態下都能提升 3-6 倍左右。

實現思路與方式:

硬體加速，雲上無法實現。

1.3.10 優化10: 優化註釋

由於無法優化瀏覽器端程式碼，當前延時只能優化到一個 RTT，若客戶端私有，可參考 TLS V1.3開發 0-RTT協議。

1.3.11 優化11: 演算法分離

利用軟優化以及硬體加速卡，基本能滿足大部分的業務場景，但這卻不是最優解，我們發現：

不同廠家不同型號的加速卡存在效能差異，同型號的加速卡不同演算法也存在效能差異，像我們測試的一款 Cavium 卡，ECDHP256 和 RSA2048_Sign 存在 20% 的效能差距

Openssl-1.0.2 版本實現了更快速以及更安全的 EC_GFp_nistz256_method 方法用於 P256 曲線操作，該方法利用了 Intel AVX 擴充套件，效能提升顯著。

在老舊的 Intel E5-2620 主機測試 Openssl-1.0.2 單核 ECDH 效能達到 8040，4 倍於 Openssl-1.0.1u，24 核全開時效能達到 9.7W，在 E5-2650 V2 上，極限效能更是達到 17.5W，遠高於加速卡單卡的 5-8W。

正是由於這種差異性，我們提出演算法分離的架構，希望充分利用硬體效能。

如上圖，通過這種架構我們把接入叢集從 CPU 密集型轉換成 IO 密集型，具體的演算法運算，私鑰儲存等都在專有叢集完成，極大地增強了接入叢集的可擴充套件性。

另外通過這種架構我們不僅可以充分利用閒置的計算資源，也可以最優化 HTTPS 解除安裝服務的吞吐率，而且對於計算叢集的增刪改，我們支援在 Web 管控端上批量修改，解除安裝服務會實時拉取並應用修改，此外再輔以計算叢集的整體監控，極大地簡化了運維複雜度。

2、Https調優壓測

任何壓力都無法完全模擬線上正常環境，隨此處僅供參考。

環境說明:

IP	配置	頻寬	域名	網站型別	伺服器座標
120.76.121.45	1核2G	1M	ssl.saevan.com	純靜態html	廣東省深圳市

辦公網環境: 座標青島，電信聯通雙線。

壓測軟體: AB

原網站ab吞吐.

[[email protected] ~]# ab -n100 -c20 http://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            80

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20  `
Time taken for tests:   14.422 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1432500 bytes
HTML transferred:       1409100 bytes
Requests per second:    6.93 [#/sec] (mean)
Time per request:       2884.332 [ms] (mean)
Time per request:       144.217 [ms] (mean, across all concurrent requests)
Transfer rate:          97.00 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:       42   46   2.9     45      60
Processing:    97 2658 1938.3   1910   12252
Waiting:       43   59  77.7     46     641
Total:        145 2703 1938.7   1961   12302

Percentage of the requests served within a certain time (ms)
  50%   1961
  66%   2883
  75%   3339
  80%   4162
  90%   5345
  95%   6364
  98%   8385
  99%  12302
 100%  12302 (longest request)

配置RSA證書後，未進行優化結果:

[[email protected] ~]# ab -n100 -c20 https://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES256-GCM-SHA384,2048,256

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20
Time taken for tests:   18.004 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1432500 bytes
HTML transferred:       1409100 bytes
Requests per second:    5.55 [#/sec] (mean)
Time per request:       3600.891 [ms] (mean)
Time per request:       180.045 [ms] (mean, across all concurrent requests)
Transfer rate:          77.70 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      142  602 585.7    403    3993
Processing:   378 2493 2099.5   1854   10143
Waiting:      374 2493 2099.7   1854   10143
Total:        520 3095 2173.7   2448   11135

Percentage of the requests served within a certain time (ms)
  50%   2448
  66%   3007
  75%   3786
  80%   4304
  90%   5531
  95%   9210
  98%  10532
  99%  11135
 100%  11135 (longest request)

優化Https後：

優化選項有:False Start、OCSP Stapling、HSTS、會話複用；

[[email protected] ~]# ab -n100 -c20 https://ssl.saevan.com/
This is ApacheBench, Version 2.3 <$Revision: 1430300 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking ssl.saevan.com (be patient).....done


Server Software:        EWS/2.2.23
Server Hostname:        ssl.saevan.com
Server Port:            443
SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128

Document Path:          /
Document Length:        14091 bytes

Concurrency Level:      20
Time taken for tests:   17.801 seconds
Complete requests:      100
Failed requests:        0
Write errors:           0
Total transferred:      1441200 bytes
HTML transferred:       1409100 bytes
Requests per second:    5.62 [#/sec] (mean)
Time per request:       3560.120 [ms] (mean)
Time per request:       178.006 [ms] (mean, across all concurrent requests)
Transfer rate:          79.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:      138  440 395.2    382    2155
Processing:    91 2742 2360.6   2000   15302
Waiting:       89 2742 2360.6   2000   15302
Total:        231 3182 2409.8   2468   15457

Percentage of the requests served within a certain time (ms)
  50%   2468
  66%   3082
  75%   3453
  80%   4480
  90%   7026
  95%   8385
  98%   9550
  99%  15457
 100%  15457 (longest request)

最終第三方對於SSL配置優化的評分

3、CA證書型別

3.1 SSL證書型別

基礎級SSL證書（域名型DV SSL），即只對域名的所有者（一般是域名管理員郵箱，比如[email protected]）進行線上檢查，傳送驗證郵件給域名管理員或以該域名結尾的郵箱，至於該域名的管理員是真實註冊的單位還是另有其人，不得而知了。

專業級SSL證書（IV SSL），會對域名所有權和證書申請人的真實身份進行驗證的專業級SSL證書適用於個人專業網站。

企業級 SSL 證書（OV SSL），是要購買者提交組織機構資料和單位授權信等在官方註冊的憑證，認證機構在簽發SSL證書前不僅僅要檢驗域名所有權，還必須對這些資料的真實合法性進行多方查驗，只有通過驗證的才能頒發SSL證書。

SSL 證書（EV SSL），與其他SSL證書一樣，都是基於SSL/TLS安全協議，都是用於網站的身份驗證和資訊在網上的傳輸加密。它跟普通SSL證書的區別也是明顯的，安全瀏覽器的位址列變綠，如果是不受信的SSL證書則拒絕顯示，如果是釣魚網站，位址列則會變成紅色，以警示使用者。

3.2 常用證書加密演算法

ECC:參考資料: https://www.wosign點com/ecc/，主要用於移動端

RSA:就是我們常用的證書型別

4、總結

如今，全世界都對HTTPS丟擲了橄欖枝：

a)微信小程式要求所有的請求必須是 HTTPS 請求

b)蘋果要求所有 IOS App 2016 年底強制使用 HTTPS 加密，雖然該計劃暫時被延期

c)百度、谷歌優先收錄 HTTPS 站點，相同權值的站點 HTTPS 排名靠前

d)Chrome 瀏覽器對 HTTP 頁面提出警告，如下圖，當前為中性警告，即預設情況下只有當 HTTP 頁面檢測到密碼或信用卡欄位時才會提示不安全，但同時 Chrome 也明確表示，該計劃將會越來越嚴格，最終會對所有 HTTP 頁面提示不安全。

通過目前軟優化無法最根本解決壓力問題，但以目前現狀，我們還沒有升級到壓力問題，通過基礎GET壓測，並未有大幅度明顯效能下降（一切測試都不能完全模擬整個生產環境）,所需根據需求先上迭代，是現在增加HTTPS的一個好的渠道。

HTTPS優化與證書

1、HTTPS效能優化

1.1 HTTPS效能損耗原因

1.2 HTTPS接入優化

1.3 來源JD老司機HTTPS優化指南

1.3.1 優化1：TLS Record Size 動態調整

1.3.2 優化2: False Start

1.3.3 優化3: OCSP Stapling

1.3.4 優化4: HSTS

1.3.5 優化5: 會話複用

1.3.6 優化6: 雙證書

1.3.7 優化7: 對稱加密優化

1.3.8 優化8: HTTP/2

1.3.9 優化9: 加速卡

1.3.10 優化10: 優化註釋

1.3.11 優化11: 演算法分離

2、Https調優壓測

3、CA證書型別

3.1 SSL證書型別

3.2 常用證書加密演算法

4、總結

相關推薦