久草中文在线观看_久久精品中文字幕一区_亚洲日本欧美日韩中文字幕_熟妇人妻无乱码中文字幕真矢织江

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

    1 前言

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

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

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

    2.1 Tcp fast open

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

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

    2.2 HSTS

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

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

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

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

    HSTS（HTTP Strict Transport Security）。服務(wù)端返回一個(gè) HSTS 的 http header，瀏覽器獲取到 HSTS 頭部之后，在一段時(shí)間內(nèi)，不管用戶輸入www.baidu.com還是http://www.baidu.com，都會(huì)默認(rèn)將請(qǐng)求內(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，實(shí)現(xiàn)簡(jiǎn)化握手。復(fù)用 session 的好處有兩個(gè)：

    1， 減少了 CPU 消耗，因?yàn)椴恍枰M(jìn)行非對(duì)稱密鑰交換的計(jì)算。

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

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

    2.3.1 Session cache

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

    Session cache 有兩個(gè)缺點(diǎn)：

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

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

    Session cache 也有一個(gè)非常大的優(yōu)點(diǎn)：

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

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

    2.3.2 Session ticket

    上節(jié)提到了 session cache 的兩個(gè)缺點(diǎn)，session ticket 能夠彌補(bǔ)這些不足。

    Session ticket 的原理參考 RFC4507。簡(jiǎn)述如下：

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

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

    Session ticket 的缺點(diǎn)：

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

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

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

    2.4 Ocsp stapling

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

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

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

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

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

    2.5 False start

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

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

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

    2.6 使用 SPDY 或者 HTTP2

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

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

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

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

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

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

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

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

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

    3.1 優(yōu)先使用 ECC

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

    QQ截圖20170609143725

    表格 2 NIST 推薦使用的密鑰長(zhǎng)度

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

    3.2 使用最新版的 openssl

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

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

    3.3 硬件加速方案

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

    1， SSL 專用加速卡。

    2， GPU SSL 加速。

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

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

    2， 升級(jí)成本高。

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

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

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

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

    3.4 TLS 遠(yuǎn)程代理計(jì)算

    也正是因?yàn)樯鲜鲈颍俣葘?shí)現(xiàn)了專用的 SSL 硬件加速集群。基本思路是：

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

    a） RSA 中的加解密計(jì)算。

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

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

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

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

    4 HTTPS 安全配置

    4.1 協(xié)議版本選擇

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

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

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

    4.2 加密套件選擇

    加密套件包含四個(gè)部分：

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

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

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

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

    4.3 HTTPS 防攻擊

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

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

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

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

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

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

    重新協(xié)商會(huì)有兩個(gè)隱患：

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

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

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

    5 結(jié)束語

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