HTTPS基于協議和配置的優化是怎樣的

本篇文章給大家分享的是有關 HTTPS基于協議和配置的優化是怎樣的，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

 基于協議和配置的優化

前言

上文講到 HTTPS 對用戶訪問速度的影響。
本文就為大家介紹 HTTPS 在訪問速度，計算性能，安全等方面基于協議和配置的優化。

HTTPS 訪問速度優化

Tcp fast open

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

HSTS

前面提到過將用戶 HTTP 請求 302 跳轉到 HTTPS，這會有兩個影響：

1. 不安全，302 跳轉不僅暴露了用戶的訪問站點，也很容易被中間者支持。

2. 降低訪問速度，302 跳轉不僅需要一個 RTT，瀏覽器執行跳轉也需要執行時間。
   由于 302 跳轉事實上是由瀏覽器觸發的，服務器無法完全控制，這個需求導致了 HSTS 的誕生：
   HSTS(HTTP Strict Transport Security)。服務端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時間內，不管用戶輸入baidu.com還是http://www.baidu.com，都會默認將請求內部跳轉成https://www.baidu.com。
   Chrome, firefox, ie 都支持了 HSTS（http://caniuse.com/#feat=stricttransportsecurity）。

Session resume

Session resume 顧名思義就是復用 session，實現簡化握手。復用 session 的好處有兩個：

1. 減少了 CPU 消耗，因為不需要進行非對稱密鑰交換的計算。

2. 提升訪問速度，不需要進行完全握手階段二，節省了一個 RTT 和計算耗時。

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

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，能夠明顯提升用戶的訪問速度，節省服務器計算資源。

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。

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 的指令就能開啟這個功能：

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。

使用 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 都沒有支持過。
   百度服務端和百度手機瀏覽器現在都已經支持1 協議。

HTTPS 計算性能優化

優先使用 ECC

ECC 橢圓加密算術相比普通的離散對數計算速度性能要強很多。下表是 NIST 推薦的密鑰長度對照表。
對稱密鑰大小 | RSA 和 DH 密鑰大小 | ECC 密鑰大小
----|------|---- 80|1024|160| 112|2048|224 128|3072|256 192|7680|384 256|15360|521 表格 2 NIST 推薦使用的密鑰長度
對于 RSA 算法來講，目前至少使用 2048 位以上的密鑰長度才能保證安全性。ECC 只需要使用 224 位長度的密鑰就能實現 RSA2048 位長度的安全強度。在進行相同的模指數運算時速度顯然要快很多。

使用最新版的 openssl

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

硬件加速方案

現在比較常用的 TLS 硬件加速方案主要有兩種：

1. SSL 專用加速卡。

2. GPU SSL 加速。 上述兩個方案的主流用法都是將硬件插入到服務器的 PCI 插槽中，由硬件完成最消耗性能的計算。但這樣的方案有如下缺點：

3. 支持算法有限。比如不支持 ECC，不支持 GCM 等。

4. 升級成本高。

• 出現新的加密算法或者協議時，硬件加速方案無法及時升級。

• 出現比較大的安全漏洞時，部分硬件方案在無法在短期內升級解決。比如 2014 年暴露的 heartbleed 漏洞。

5. 無法充分利用硬件加速性能。硬件加速程序一般都運行在內核態，計算結果傳遞到應用層需要 IO 和內存拷貝開銷，即使硬件計算性能非常好，上層的同步等待和 IO 開銷也會導致整體性能達不到預期，無法充分利用硬件加速卡的計算能力。

6. 維護性差。硬件驅動及應用層 API 大部分是由安全廠家提供，出現問題后還需要廠家跟進。用戶無法掌握核心代碼，比較被動。不像開源的 openssl，不管算法還是協議，用戶都能掌握。

TLS 遠程代理計算

也正是因為上述原因，百度實現了專用的 SSL 硬件加速集群。基本思路是：

1. 優化 TLS 協議棧，剝離最消耗 CPU 資源的計算，主要有如下部分：

• RSA 中的加解密計算。

• ECC 算法中的公私鑰生成。

• ECC 算法中的共享密鑰生成。

2. 優化硬件計算部分。硬件計算不涉及協議及狀態交互，只需要處理大數運算。

3. Web server 到 TLS 計算集群之間的任務是異步的。即 web server 將待計算內容發送給加速集群后，依然可以繼續處理其他請求，整個過程是異步非阻塞的。

HTTPS 安全配置

協議版本選擇

SSL2.0 早就被證明是不安全的協議了，統計發現目前已經沒有客戶端支持 SSL2.0，所以可以放心地在服務端禁用 SSL2.0 協議。
2014 年爆發了 POODLE 攻擊，SSL3.0 因此被證明是不安全的。但是統計發現依然有 0.5% 的流量只支持 SSL3.0。所以只能有選擇地支持 SSL3.0。
TLS1.1 及 1.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 算法，針對0 以上協議禁用 RC4（ rfc7465）。

4. 內容一致性校驗算法。Md5 和 sha1 都已經不安全，建議使用 sha2 以上的安全哈希函數。

HTTPS 防攻擊

防止協議降級攻擊

降級攻擊一般包括兩種：加密套件降級攻擊 (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，就不會接受比服務端最高協議版本低的協議。

防止重新協商攻擊

重新協商（tls renegotiation）分為兩種：加密套件重協商 (cipher suite renegotiation) 和協議重協商（protocol renegotiation）。
重新協商會有兩個隱患：

1. 重協商后使用弱的安全算法。這樣的后果就是傳輸內容很容易泄露。

2. 重協商過程中不斷發起完全握手請求，觸發服務端進行高強度計算并引發服務拒絕。 對于重協商，最直接的保護手段就是禁止客戶端主動重協商，當然出于特殊場景的需求，應該允許服務端主動發起重協商。

以上就是 HTTPS基于協議和配置的優化是怎樣的，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。