HTTPS優化與證書

一、HTTPS性能優化

1.1 HTTPS性能損耗緣由

前文討論了HTTPS原理與優點：身份驗證、信息加密與完整性校驗等，且未對TCP和HTTP協議作任何修改。但經過增長新協議以實現更安全的通訊必然須要付出代價，HTTPS協議的性能損耗主要體現以下：

一、增長延時

分析前面的握手過程，一次完整的握手至少須要兩端依次來回兩次通訊，至少增長延時2* RTT，利用會話緩存從而複用鏈接，延時也至少1* RTT*。

二、消耗較多的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接入優化

一、CDN接入

HTTPS 增長的延時主要是傳輸延時 RTT，RTT 的特色是節點越近延時越小，CDN 自然離用戶最近，所以選擇使用 CDN 做爲 HTTPS 接入的入口，將可以極大減小接入延時。CDN 節點經過和業務服務器維持長鏈接、會話複用和鏈路質量優化等可控方法，極大減小 HTTPS 帶來的延時。

二、會話緩存

雖然前文提到 HTTPS 即便採用會話緩存也要至少1*RTT的延時，可是至少延時已經減小爲原來的一半，明顯的延時優化;同時，基於會話緩存創建的 HTTPS 鏈接不須要服務器使用RSA私鑰解密獲取 Pre-master 信息，能夠省去CPU 的消耗。若是業務訪問鏈接集中，緩存命中率高，則HTTPS的接入能力講明顯提高。當前TRP平臺的緩存命中率高峯時期大於30%，10k/s的接入資源實際能夠承載13k/的接入，收效很是可觀。

三、硬件加速

爲接入服務器安裝專用的SSL硬件加速卡，做用相似 GPU，釋放 CPU，可以具備更高的 HTTPS 接入能力且不影響業務程序的。測試某硬件加速卡單卡能夠提供35k的解密能力，至關於175核 CPU，至少至關於7臺24核的服務器，考慮到接入服務器其它程序的開銷，一張硬件卡能夠實現接近10臺服務器的接入能力。

四、遠程解密

本地接入消耗過多的 CPU 資源，浪費了網卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它服務器，如此則能夠充分發揮服務器的接入能力，充分利用帶寬與網卡資源。遠程解密服務器能夠選擇 CPU 負載較低的機器充當，實現機器資源複用，也能夠是專門優化的高計算性能的服務器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。

五、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;

參考資料: http://www.javashuo.com/article/p-nngitqez-gn.html

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 管控端上批量修改，卸載服務會實時拉取並應用修改，此外再輔以計算集羣的總體監控，極大地簡化了運維複雜度。

二、Https調優壓測

任何壓力都沒法徹底模擬線上正常環境，隨此處僅供參考。

環境說明:

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

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

壓測軟件: AB

原網站ab吞吐.

[root@evan-node-1 ~]# 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證書後，未進行優化結果:

[root@evan-node-1 ~]# 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、會話複用；

[root@evan-node-1 ~]# 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配置優化的評分

三、CA證書類型

3.1 SSL證書類型

基礎級SSL證書（域名型DV SSL） ，即只對域名的全部者（通常是域名管理員郵箱，好比admin@hotmail.com）進行在線檢查，發送驗證郵件給域名管理員或以該域名結尾的郵箱，至於該域名的管理員是真實註冊的單位仍是另有其人，不得而知了。

專業級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:就是咱們經常使用的證書類型

四、總結

現在，全世界都對HTTPS拋出了橄欖枝：

​ a)微信小程序要求全部的請求必須是 HTTPS 請求

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

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

​ d)Chrome 瀏覽器對 HTTP 頁面提出警告，以下圖，當前爲中性警告，即默認狀況下只有當 HTTP 頁面檢測到密碼或信用卡字段時纔會提示不安全，但同時 Chrome 也明確表示，該計劃將會愈來愈嚴格，最終會對全部 HTTP 頁面提示不安全。

​ 經過目前軟優化沒法最根本解決壓力問題，但以目前現狀，咱們尚未升級到壓力問題，經過基礎GET壓測，並未有大幅度明顯性能降低（一切測試都不能徹底模擬整個生產環境）,所需根據需求先上迭代，是如今增長HTTPS的一個好的渠道。