91麻豆精品在线观看_一级做性色a爰片久久毛片免费_zzijzzij亚洲日本少妇jizjiz_国产日产欧美欧韩在线_日本高清在线www3344

    百度在2015年即完成HTTPS改造，那大型網(wǎng)站的HTTPS改造中都有哪些實踐經(jīng)驗，學(xué)院君特分析這篇干貨滿滿系列內(nèi)容，轉(zhuǎn)自百度運維博客。

    1 前言

    上文講到 HTTPS 對用戶訪問速度的影響。

    本文就為大家介紹 HTTPS 在訪問速度，計算性能，安全等方面基于協(xié)議和配置的優(yōu)化。

    2 HTTPS 訪問速度優(yōu)化

    2.1 Tcp fast open

    HTTPS 和 HTTP 使用 TCP 協(xié)議進行傳輸，也就意味著必須通過三次握手建立 TCP 連接，但一個 RTT 的時間內(nèi)只傳輸一個 syn 包是不是太浪費？能不能在 syn 包發(fā)出的同時捎上應(yīng)用層的數(shù)據(jù)？其實是可以的，這也是 tcp fast open 的思路，簡稱 TFO。具體原理可以參考 rfc7413。

    遺憾的是 TFO 需要高版本內(nèi)核的支持，linux 從 3.7 以后支持 TFO，但是目前的 windows 系統(tǒng)還不支持 TFO，所以只能在公司內(nèi)部服務(wù)器之間發(fā)揮作用。

    2.2 HSTS

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

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

    2， 降低訪問速度，302 跳轉(zhuǎn)不僅需要一個 RTT，瀏覽器執(zhí)行跳轉(zhuǎn)也需要執(zhí)行時間。

    由于 302 跳轉(zhuǎn)事實上是由瀏覽器觸發(fā)的，服務(wù)器無法完全控制，這個需求導(dǎo)致了 HSTS 的誕生：

    HSTS（HTTP Strict Transport Security）。服務(wù)端返回一個 HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時間內(nèi)，不管用戶輸入www.baidu.com還是http://www.baidu.com，都會默認將請求內(nèi)部跳轉(zhuǎn)成https://www.baidu.com。

    Chrome, firefox, ie 都支持了 HSTS（http://caniuse.com/#feat=stricttransportsecurity）。

    2.3 Session resume

    Session resume 顧名思義就是復(fù)用 session，實現(xiàn)簡化握手。復(fù)用 session 的好處有兩個：

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

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

    TLS 協(xié)議目前提供兩種機制實現(xiàn) session resume，分別介紹一下。

    2.3.1 Session cache

    Session cache 的原理是使用 client hello 中的 session id 查詢服務(wù)端的 session cache, 如果服務(wù)端有對應(yīng)的緩存，則直接使用已有的 session 信息提前完成握手，稱為簡化握手。

    Session cache 有兩個缺點：

    1， 需要消耗服務(wù)端內(nèi)存來存儲 session 內(nèi)容。

    2， 目前的開源軟件包括 nginx,apache 只支持單機多進程間共享緩存，不支持多機間分布式緩存，對于百度或者其他大型互聯(lián)網(wǎng)公司而言，單機 session cache 幾乎沒有作用。

    Session cache 也有一個非常大的優(yōu)點：

    1， session id 是 TLS 協(xié)議的標(biāo)準(zhǔn)字段，市面上的瀏覽器全部都支持 session cache。

    百度通過對 TLS 握手協(xié)議及服務(wù)器端實現(xiàn)的優(yōu)化，已經(jīng)支持全局的 session cache，能夠明顯提升用戶的訪問速度，節(jié)省服務(wù)器計算資源。

    2.3.2 Session ticket

    上節(jié)提到了 session cache 的兩個缺點，session ticket 能夠彌補這些不足。

    Session ticket 的原理參考 RFC4507。簡述如下：

    server 將 session 信息加密成 ticket 發(fā)送給瀏覽器，瀏覽器后續(xù)握手請求時會發(fā)送 ticket，server 端如果能成功解密和處理 ticket，就能完成簡化握手。

    顯然，session ticket 的優(yōu)點是不需要服務(wù)端消耗大量資源來存儲 session 內(nèi)容。

    Session ticket 的缺點：

    1， session ticket 只是 TLS 協(xié)議的一個擴展特性，目前的支持率不是很廣泛，只有 60% 左右。

    2， session ticket 需要維護一個全局的 key 來加解密，需要考慮 KEY 的安全性和部署效率。

    總體來講，session ticket 的功能特性明顯優(yōu)于 session cache。希望客戶端實現(xiàn)優(yōu)先支持 session ticket。

    2.4 Ocsp stapling

    Ocsp 全稱在線證書狀態(tài)檢查協(xié)議 （rfc6960），用來向 CA 站點查詢證書狀態(tài)，比如是否撤銷。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請求，CA 返回證書狀態(tài)內(nèi)容，然后瀏覽器接受證書是否可信的狀態(tài)。

    這個過程非常消耗時間，因為 CA 站點有可能在國外，網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大。那有沒有辦法不直接向 CA 站點請求 OCSP 內(nèi)容呢？ocsp stapling 就能實現(xiàn)這個功能。

    詳細介紹參考 RFC6066 第 8 節(jié)。簡述原理就是瀏覽器發(fā)起 client hello 時會攜帶一個 certificate status request 的擴展，服務(wù)端看到這個擴展后將 OCSP 內(nèi)容直接返回給瀏覽器，完成證書狀態(tài)檢查。

    由于瀏覽器不需要直接向 CA 站點查詢證書狀態(tài)，這個功能對訪問速度的提升非常明顯。

    Nginx 目前已經(jīng)支持這個 ocsp stapling file，只需要配置 ocsp stapling file 的指令就能開啟這個功能：

    2.5 False start

    通常情況下，應(yīng)用層數(shù)據(jù)必須等完全握手全部結(jié)束之后才能傳輸。這個其實比較浪費時間，那能不能類似 TFO 一樣，在完全握手的第二個階段將應(yīng)用數(shù)據(jù)一起發(fā)出來呢？google 提出了 false start 來實現(xiàn)這個功能。詳細介紹參考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00。

    簡單概括 False start 的原理就是在 client_key_exchange 發(fā)出時將應(yīng)用層數(shù)據(jù)一起發(fā)出來，能夠節(jié)省一個 RTT。

    False start 依賴于 PFS（perfect forward secrecy 完美前向加密），而 PFS 又依賴于 DHE 密鑰交換系列算法（DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA），所以盡量優(yōu)先支持 ECDHE 密鑰交換算法實現(xiàn) false start。

    2.6 使用 SPDY 或者 HTTP2

    SPDY 是 google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議（https://www.chromium.org/spdy），它基本上沿用了 HTTP 協(xié)議的語義， 但是通過使用幀控制實現(xiàn)了多個特性，顯著提升了 HTTP 協(xié)議的傳輸效率。

    SPDY 最大的特性就是多路復(fù)用，能將多個 HTTP 請求在同一個連接上一起發(fā)出去，不像目前的 HTTP 協(xié)議一樣，只能串行地逐個發(fā)送請求。Pipeline 雖然支持多個請求一起發(fā)送，但是接收時依然得按照順序接收，本質(zhì)上無法解決并發(fā)的問題。

    HTTP2 是 IETF 2015 年 2 月份通過的 HTTP 下一代協(xié)議，它以 SPDY 為原型，經(jīng)過兩年多的討論和完善最終確定。

    本文就不過多介紹 SPDY 和 HTTP2 的收益，需要說明兩點：

    1， SPDY 和 HTTP2 目前的實現(xiàn)默認使用 HTTPS 協(xié)議。

    2， SPDY 和 HTTP2 都支持現(xiàn)有的 HTTP 語義和 API，對 WEB 應(yīng)用幾乎是透明的。

    Google 宣布 chrome 瀏覽器 2016 年將放棄 SPDY 協(xié)議，全面支持 HTTP2，但是目前國內(nèi)部分瀏覽器廠商進度非常慢，不僅不支持 HTTP2，連 SPDY 都沒有支持過。

    百度服務(wù)端和百度手機瀏覽器現(xiàn)在都已經(jīng)支持 SPDY3.1 協(xié)議。

    3 HTTPS 計算性能優(yōu)化

    3.1 優(yōu)先使用 ECC

    ECC 橢圓加密算術(shù)相比普通的離散對數(shù)計算速度性能要強很多。下表是 NIST 推薦的密鑰長度對照表。

    QQ截圖20170609143725

    表格 2 NIST 推薦使用的密鑰長度

    對于 RSA 算法來講，目前至少使用 2048 位以上的密鑰長度才能保證安全性。ECC 只需要使用 224 位長度的密鑰就能實現(xiàn) RSA2048 位長度的安全強度。在進行相同的模指數(shù)運算時速度顯然要快很多。

    3.2 使用最新版的 openssl

    一般來講，新版的 openssl 相比老版的計算速度和安全性都會有提升。比如 openssl1.0.2 采用了 intel 最新的優(yōu)化成果，橢圓曲線 p256 的計算性能提升了 4 倍。（https://eprint.iacr.org/2013/816.pdf）

    Openssl 2014 年就升級了 5 次，基本都是為了修復(fù)實現(xiàn)上的 BUG 或者算法上的漏洞而升級的。所以盡量使用最新版本，避免安全上的風(fēng)險。

    3.3 硬件加速方案

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

    1， SSL 專用加速卡。

    2， GPU SSL 加速。

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

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

    2， 升級成本高。

    a） 出現(xiàn)新的加密算法或者協(xié)議時，硬件加速方案無法及時升級。

    b） 出現(xiàn)比較大的安全漏洞時，部分硬件方案在無法在短期內(nèi)升級解決。比如 2014 年暴露的 heartbleed 漏洞。

    3， 無法充分利用硬件加速性能。硬件加速程序一般都運行在內(nèi)核態(tài)，計算結(jié)果傳遞到應(yīng)用層需要 IO 和內(nèi)存拷貝開銷，即使硬件計算性能非常好，上層的同步等待和 IO 開銷也會導(dǎo)致整體性能達不到預(yù)期，無法充分利用硬件加速卡的計算能力。

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

    3.4 TLS 遠程代理計算

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

    1， 優(yōu)化 TLS 協(xié)議棧，剝離最消耗 CPU 資源的計算，主要有如下部分：

    a） RSA 中的加解密計算。

    b） ECC 算法中的公私鑰生成。

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

    2， 優(yōu)化硬件計算部分。硬件計算不涉及協(xié)議及狀態(tài)交互，只需要處理大數(shù)運算。

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

    4 HTTPS 安全配置

    4.1 協(xié)議版本選擇

    SSL2.0 早就被證明是不安全的協(xié)議了，統(tǒng)計發(fā)現(xiàn)目前已經(jīng)沒有客戶端支持 SSL2.0，所以可以放心地在服務(wù)端禁用 SSL2.0 協(xié)議。

    2014 年爆發(fā)了 POODLE 攻擊，SSL3.0 因此被證明是不安全的。但是統(tǒng)計發(fā)現(xiàn)依然有 0.5% 的流量只支持 SSL3.0。所以只能有選擇地支持 SSL3.0。

    TLS1.1 及 1.2 目前為止沒有發(fā)現(xiàn)安全漏洞，建議優(yōu)先支持。

    4.2 加密套件選擇

    加密套件包含四個部分：

    1， 非對稱密鑰交換算法。建議優(yōu)先使用 ECDHE，禁用 DHE，次優(yōu)先選擇 RSA。

    2， 證書簽名算法。由于部分瀏覽器及操作系統(tǒng)不支持 ECDSA 簽名，目前默認都是使用 RSA 簽名，其中 SHA1 簽名已經(jīng)不再安全，chrome 及微軟 2016 年開始不再支持 SHA1 簽名的證書 （http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html）。

    3， 對稱加解密算法。優(yōu)先使用 AES-GCM 算法，針對 1.0 以上協(xié)議禁用 RC4（ rfc7465）。

    4， 內(nèi)容一致性校驗算法。Md5 和 sha1 都已經(jīng)不安全，建議使用 sha2 以上的安全哈希函數(shù)。

    4.3 HTTPS 防攻擊

    4.3.1 防止協(xié)議降級攻擊

    降級攻擊一般包括兩種：加密套件降級攻擊 （cipher suite rollback） 和協(xié)議降級攻擊（version roll back）。降級攻擊的原理就是攻擊者偽造或者修改 client hello 消息，使得客戶端和服務(wù)器之間使用比較弱的加密套件或者協(xié)議完成通信。

    為了應(yīng)對降級攻擊，現(xiàn)在 server 端和瀏覽器之間都實現(xiàn)了 SCSV 功能，原理參考https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00。

    一句話解釋就是如果客戶端想要降級，必須發(fā)送 TLS_SCSV 的信號，服務(wù)器如果看到 TLS_SCSV，就不會接受比服務(wù)端最高協(xié)議版本低的協(xié)議。

    4.3.2 防止重新協(xié)商攻擊

    重新協(xié)商（tls renegotiation）分為兩種：加密套件重協(xié)商 （cipher suite renegotiation） 和協(xié)議重協(xié)商（protocol renegotiation）。

    重新協(xié)商會有兩個隱患：

    1， 重協(xié)商后使用弱的安全算法。這樣的后果就是傳輸內(nèi)容很容易泄露。

    2， 重協(xié)商過程中不斷發(fā)起完全握手請求，觸發(fā)服務(wù)端進行高強度計算并引發(fā)服務(wù)拒絕。

    對于重協(xié)商，最直接的保護手段就是禁止客戶端主動重協(xié)商，當(dāng)然出于特殊場景的需求，應(yīng)該允許服務(wù)端主動發(fā)起重協(xié)商。

    5 結(jié)束語

    HTTPS 的實踐和優(yōu)化涉及到了非常多的知識點，由于篇幅關(guān)系，本文對很多優(yōu)化策略只是簡單介紹了一下。 如果想要了解協(xié)議背后的原理，還是需要詳細閱讀 TLS 協(xié)議及 PKI 知識。對于大型站點來說，如果希望做到極致，HTTPS 的部署需要結(jié)合產(chǎn)品和基礎(chǔ)設(shè)施的架構(gòu)來進行詳細的考慮，比起部署支持 HTTPS 的接入和對它的優(yōu)化，在產(chǎn)品和運維層面上花費的功夫會更多。本系列的下一篇文章將進一步進行介紹。