HTTPS 站點的性能優化

HTTPS 站中的幾大難題

性能，包括：

1. HTTPS須要屢次握手，所以網絡耗時變長，用戶從HTTP跳轉到HTTPS須要一些時間；
2. HTTPS要作RSA校驗，這會影響到設備性能；
3. 全部CDN節點要支持HTTPS，並且須要有極其複雜的解決方案來面對DDoS的挑戰。

其次，兼容性及周邊，如：

1. 頁面裏全部嵌入的資源都要改爲HTTPS的，這些資源可能會來自不一樣的部門甚至不一樣的公司，包括圖片、視頻、表單等等，不然瀏覽器就會報警。

如何解決

• 採用了統一接入層的架構，並配備管控平臺。這樣的設計解決了不少問題，好比證書分散且落地不安全、軟件版本難以維護、配置過多、難以標準和自動化、VIP 過多等；
• 以域名收斂的方式減小建連；
• 採用 HSTS 技術去掉 80 到 443 的 302 跳轉；
• 經過 Session 複用來提升建連速度和下降服務器壓力；
• 對證書鏈進行優化以減小證書的傳輸量；
• 摒棄傳統的 RSA 算法，轉而使用了最新的 ECDH 密鑰交換算法，極大地提高了服務端的性能。

關注安全與兼容性

• 採用了雙證書模式，即SHA-1和SHA-256，最大限度地保證安全和兼容性；
• 使用的是兼容性最寬泛的 OV 證書，全面支持單域名、多域名和泛域名，知足多種瀏覽器訪問，保證最好的用戶體驗，固然代價也是費用較爲昂貴；
• 引入泛域名 SAN 證書。

其次是一篇關於 Nginx 中 SSL 性能優化的文章《Nginx SSL 性能優化》。

密鑰交換算法

常見的密鑰交換算法有 RSA，ECDHE，DH，DHE 等算法。它們的特性以下：

• RSA：算法實現簡單，誕生於 1977 年，歷史悠久，通過了長時間的破解測試，安全性高。缺點就是須要比較大的素數（目前經常使用的是 2048 位）來保證安全強度，很消耗 CPU 運算資源。RSA 是目前惟一一個既能用於密鑰交換又能用於證書籤名的算法。
• DH：diffie-hellman 密鑰交換算法，誕生時間比較早（1977 年），可是 1999 年才公開。缺點是比較消耗 CPU 性能。
• ECDHE：使用橢圓曲線（ECC）的 DH 算法，優勢是能用較小的素數（256 位）實現 RSA 相同的安全等級。缺點是算法實現複雜，用於密鑰交換的歷史不長，沒有通過長時間的安全攻擊測試。
• ECDH：不支持 PFS，安全性低，同時沒法實現 false start。
• DHE：不支持 ECC。很是消耗 CPU 資源 。

建議優先支持 RSA 和 ECDH_RSA 密鑰交換算法。緣由是：

• ECDHE 支持 ECC 加速，計算速度更快。支持 PFS，更加安全。支持 false start，用戶訪問速度更快。
• 目前還有至少 20% 以上的客戶端不支持 ECDHE，咱們推薦使用 RSA 而不是 DH 或者 DHE，由於 DH 系列算法很是消耗 CPU（至關於要作兩次 RSA 計算）。

更改其配置以下（參照 Nginx Performance Tuning for SSL（ http://dojo.techsamurais.com/?p=1384 ）：

1 2 3 4 5

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;

或者

1

ssl_ciphers ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-RC4-SHA:!ECDHE-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:!RC4-SHA:HIGH:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!CBC:!EDH:!kEDH:!PSK:!SRP:!kECDH;

（禁用了RC4，sha1，MD5等算法）

輔助加速

啓用SPDY

SPDY 是 Google 推出的優化 HTTP 傳輸效率的協議（ https://www.chromium.org/spdy ）, 它基本上沿用了 HTTP 協議的語義, 可是經過使用幀控制實現了多個特性，顯著提高了 HTTP 協議的傳輸效率。

SPDY 最大的特性就是多路複用，能將多個 HTTP 請求在同一個鏈接上一塊兒發出去，不像目前的 HTTP 協議同樣，只能串行地逐個發送請求。

能夠在編譯Nginx帶上參數 –with-http_spdy_module 支持 SPDY 協議，而後可在配置中啓用：

1	listen 443 ssl spdy;

檢測是否使用SPDY的網址（ https://spdycheck.org/ ）

HSTS

HSTS(HTTP Strict Transport Security)。服務端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部以後，在一段時間內，無論用戶輸入 www.baidu.com 仍是 http://www.baidu.com ，都會默認將請求內部跳轉成 https://www.baidu.com;

將下述行添加到你的 HTTPS 配置的 server 塊中：

1	add_header Strict-Transport-Security "max-age=31536000";

Session cache

Session cache 的原理是使用 client hello 中的 session id 查詢服務端的 session cache, 若是服務端有對應的緩存，則直接使用已有的 session 信息提早完成握手，稱爲簡化握手。

Session cache 有兩個缺點：

1. 須要消耗服務端內存來存儲 session 內容。
2. 目前的開源軟件包括 nginx,apache 只支持單機多進程間共享緩存，不支持多機間分佈式緩存，對於百度或者其餘大型互聯網公司而言，單機 session cache 幾乎沒有做用。

Session cache 也有一個很是大的優勢：session id 是 TLS 協議的標準字段，市面上的瀏覽器所有都支持 session cache。

1 2	ssl_session_cache shared:SSL:20m; ssl_session_timeout 20m;

參照 Nginx 的官方文檔 1MB 內存大約能夠存儲 4000 個 session，按例配置 20M 大約能夠存儲 80000。根據需求合理設置。

Ocsp stapling

Ocsp 全稱在線證書狀態檢查協議 (rfc6960)，用來向 CA 站點查詢證書狀態，好比是否撤銷。一般狀況下，瀏覽器使用 OCSP 協議發起查詢請求，CA 返回證書狀態內容，而後瀏覽器接受證書是否可信的狀態。 將證書保存下來，瀏覽器請求時候直接經過本身的服務器發送回去，防止驗證服務器出問題，還能加快訪問速度。

查看OSCP驗證服務器地址：

1	openssl x509 -in 1_test.qupeiyin.net_bundle.crt  -text

在輸出的文字中找到 OCSP - URI: ，後面的 URL 就是 OSCP 的驗證服務器地址。

請求 OSCP 證書

1 2 3 4

openssl ocsp -noverify \ -issuer /certificate-path/trustchain.crt \ -cert /certificate-path/trustchain.crt \ -url http://ocsp1.wosign.com/ca6/server1

不出意外會收到以下的結果

1 2 3

trustchain.crt: good             This Update: Oct 18 17:59:10 2014 GMT             Next Update: Oct 18 23:59:10 2014 GMT

若是出現 403 錯誤，那就須要在 Header 請求頭加上域名參數如 -header 「HOST」 「ocsp2.globalsign.com」 ，沒問題後就能夠直接保存下來證書文件，完整的命令以下：

1 2 3 4

openssl ocsp -noverify  -issuer 1_root_bundle.crt -cert 1_root_bundle.crt -url http://ocsp1.wosign.com/ca6/server1  -header "HOST" "ocsp1.wosign.com" -text -respout ./stapling_file.ocsp

將保存下來的 stapling_file.ocsp 證書添加到 nginx 的配置中，以下，Nginx 中配置變成了這樣子：

1 2 3 4

ssl_stapling on; ssl_stapling_verify on; ssl_stapling_file /stapling_file.ocsp; ssl_trusted_certificate /certificate-path/trustchain.crt;

這樣子重啓 Nginx 後就會生效，可使用下面的命令測試生效結果：

1	echo QUIT | openssl s_client -connect blog.alphatr.com:443 -status 2> /dev/null | grep -A 17 'OCSP response:' | grep -B 17 'Next Update'

看到 OCSP Response Status: successful 這樣的字樣就是成功了。

ocsp證書有效期很短，大概不到一個月，因此過段時間要更新 ocsp 證書，否則仍是會驗證失敗。須要用腳本定時更新OCSP證書。

總結：（所有優化參數）

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

ssl on; ssl_certificate /data/www/ssl/ssl.crt; ssl_certificate_key /data/www/ssl/ssl.key; ssl_trusted_certificate /data/www/ssl/trustchain.crt; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!eNULL:!NULL:!DH:!EDH:!AESGCM; ssl_prefer_server_ciphers on; ssl_stapling on; ssl_stapling_verify on; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; add_header Strict-Transport-Security "max-age=31536000"; resolver 223.5.5.5 223.6.6.6 valid=300s; resolver_timeout 10s; error_page 497 https://$host$request_uri;

參數詳解：

ssl on  開啓SSL

ssl_certificate  對應單張證書

ssl_certificate_key  對應私鑰

ssl_trusted_certificate  對應信任鏈(即Startcom SSL或者Positive SSL中須要附加到單張證書後面的那兩張證書，能夠獨立出來)

ssl_protocols  支持的SSL協議標準（nginx默認參數爲：ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;）

ssl_ciphers  （nginx默認參數爲：ssl_ciphers HIGH:!aNULL:!MD5;）

ssl_prefer_server_ciphers On;  指定服務器密碼算法在優先於客戶端密碼算法時，使用SSLv3和TLS協議。

error_page 497 https://$host$request_uri;  經過497錯誤將http轉跳到https