HTTPS ****訪問(wèn)速度優(yōu)化

Tcp fast open

HTTPS 和 HTTP 使用 TCP 協(xié)議進(jìn)行傳輸兔魂，也就意味著必須通過(guò)三次握手建立 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ā)揮作用纹烹。

HSTS

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

1. 不安全，302 跳轉(zhuǎn)不僅暴露了用戶的訪問(wèn)站點(diǎn)铺呵，也很容易被中間者支持裹驰。
2. 降低訪問(wèn)速度，302 跳轉(zhuǎn)不僅需要一個(gè) RTT片挂，瀏覽器執(zhí)行跳轉(zhuǎn)也需要執(zhí)行時(shí)間幻林。
   由于 302 跳轉(zhuǎn)事實(shí)上是由瀏覽器觸發(fā)的贞盯，服務(wù)器無(wú)法完全控制，這個(gè)需求導(dǎo)致了 HSTS 的誕生：
   HSTS(HTTP Strict Transport Security)沪饺。服務(wù)端返回一個(gè) HSTS 的 http header躏敢，瀏覽器獲取到 HSTS 頭部之后，在一段時(shí)間內(nèi)整葡，不管用戶輸入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）掘宪。

Session resume

Session resume 顧名思義就是復(fù)用 session蛾扇，實(shí)現(xiàn)簡(jiǎn)化握手攘烛。復(fù)用 session 的好處有兩個(gè)：

1. 減少了 CPU 消耗魏滚，因?yàn)椴恍枰M(jìn)行非對(duì)稱密鑰交換的計(jì)算。
2. 提升訪問(wèn)速度坟漱，不需要進(jìn)行完全握手階段二鼠次，節(jié)省了一個(gè) RTT 和計(jì)算耗時(shí)。

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

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)存來(lái)存儲(chǔ) session 內(nèi)容。
2. 目前的開(kāi)源軟件包括 nginx,apache 只支持單機(jī)多進(jìn)程間共享緩存栅炒，不支持多機(jī)間分布式緩存掂摔，對(duì)于百度或者其他大型互聯(lián)網(wǎng)公司而言，單機(jī) session cache 幾乎沒(méi)有作用赢赊。

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

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

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

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ù)端消耗大量資源來(lái)存儲(chǔ) session 內(nèi)容。
Session ticket 的缺點(diǎn)：

1. session ticket 只是 TLS 協(xié)議的一個(gè)擴(kuò)展特性贩猎，目前的支持率不是很廣泛熊户，只有 60% 左右。
2. session ticket 需要維護(hù)一個(gè)全局的 key 來(lái)加解密吭服，需要考慮 KEY 的安全性和部署效率嚷堡。

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

Ocsp stapling

Ocsp 全稱在線證書(shū)狀態(tài)檢查協(xié)議 (rfc6960)，用來(lái)向 CA 站點(diǎn)查詢證書(shū)狀態(tài)沼琉，比如是否撤銷(xiāo)北苟。通常情況下，瀏覽器使用 OCSP 協(xié)議發(fā)起查詢請(qǐng)求打瘪，CA 返回證書(shū)狀態(tài)內(nèi)容友鼻，然后瀏覽器接受證書(shū)是否可信的狀態(tài)。
這個(gè)過(guò)程非常消耗時(shí)間闺骚，因?yàn)?CA 站點(diǎn)有可能在國(guó)外彩扔，網(wǎng)絡(luò)不穩(wěn)定，RTT 也比較大僻爽。那有沒(méi)有辦法不直接向 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)容直接返回給瀏覽器，完成證書(shū)狀態(tài)檢查乳绕。
由于瀏覽器不需要直接向 CA 站點(diǎn)查詢證書(shū)狀態(tài)绞惦，這個(gè)功能對(duì)訪問(wèn)速度的提升非常明顯。
Nginx 目前已經(jīng)支持這個(gè) ocsp stapling file洋措，只需要配置 ocsp stapling file 的指令就能開(kāi)啟這個(gè)功能：

image

False start

通常情況下济蝉，應(yīng)用層數(shù)據(jù)必須等完全握手全部結(jié)束之后才能傳輸。這個(gè)其實(shí)比較浪費(fèi)時(shí)間菠发，那能不能類似 TFO 一樣王滤，在完全握手的第二個(gè)階段將應(yīng)用數(shù)據(jù)一起發(fā)出來(lái)呢？google 提出了 false start 來(lái)實(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ā)出來(lái)，能夠節(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。

使用**** SPDY ****或者**** HTTP2

SPDY 是 google 推出的優(yōu)化 HTTP 傳輸效率的協(xié)議（https://www.chromium.org/spdy）珠月，它基本上沿用了HTTP 協(xié)議的語(yǔ)義 , 但是通過(guò)使用幀控制實(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ì)上無(wú)法解決并發(fā)的問(wèn)題伙判。
HTTP2 是 IETF 2015 年 2 月份通過(guò)的 HTTP 下一代協(xié)議象对，它以 SPDY 為原型，經(jīng)過(guò)兩年多的討論和完善最終確定澳腹。
本文就不過(guò)多介紹 SPDY 和 HTTP2 的收益织盼，需要說(shuō)明兩點(diǎn)：

1. SPDY 和 HTTP2 目前的實(shí)現(xiàn)默認(rèn)使用 HTTPS 協(xié)議。
2. SPDY 和 HTTP2 都支持現(xiàn)有的 HTTP 語(yǔ)義和 API酱塔，對(duì) WEB 應(yīng)用幾乎是透明的。
   Google 宣布 chrome 瀏覽器 2016 年將放棄 SPDY 協(xié)議危虱，全面支持 HTTP2羊娃，但是目前國(guó)內(nèi)部分瀏覽器廠商進(jìn)度非常慢，不僅不支持 HTTP2埃跷，連 SPDY 都沒(méi)有支持過(guò)蕊玷。
   百度服務(wù)端和百度手機(jī)瀏覽器現(xiàn)在都已經(jīng)支持1 協(xié)議。

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

優(yōu)先使用**** ECC

ECC 橢圓加密算術(shù)相比普通的離散對(duì)數(shù)計(jì)算速度性能要強(qiáng)很多弥雹。下表是 NIST 推薦的密鑰長(zhǎng)度對(duì)照表垃帅。
對(duì)稱密鑰大小 | RSA 和 DH 密鑰大小 | ECC 密鑰大小
----|------|---- 80|1024|160| 112|2048|224 128|3072|256 192|7680|384 256|15360|521 表格 2 NIST 推薦使用的密鑰長(zhǎng)度
對(duì)于 RSA 算法來(lái)講，目前至少使用 2048 位以上的密鑰長(zhǎng)度才能保證安全性剪勿。ECC 只需要使用 224 位長(zhǎng)度的密鑰就能實(shí)現(xiàn) RSA2048 位長(zhǎng)度的安全強(qiáng)度贸诚。在進(jìn)行相同的模指數(shù)運(yùn)算時(shí)速度顯然要快很多。

使用最新版的**** openssl

一般來(lái)講厕吉，新版的 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)班眯。

硬件加速方案

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

1. SSL 專用加速卡希停。
2. GPU SSL 加速。 上述兩個(gè)方案的主流用法都是將硬件插入到服務(wù)器的 PCI 插槽中署隘，由硬件完成最消耗性能的計(jì)算脖苏。但這樣的方案有如下缺點(diǎn)：
3. 支持算法有限。比如不支持 ECC定踱，不支持 GCM 等棍潘。
4. 升級(jí)成本高。
   • 出現(xiàn)新的加密算法或者協(xié)議時(shí)崖媚，硬件加速方案無(wú)法及時(shí)升級(jí)亦歉。
   • 出現(xiàn)比較大的安全漏洞時(shí)，部分硬件方案在無(wú)法在短期內(nèi)升級(jí)解決畅哑。比如 2014 年暴露的 heartbleed 漏洞肴楷。
5. 無(wú)法充分利用硬件加速性能。硬件加速程序一般都運(yùn)行在內(nèi)核態(tài)荠呐，計(jì)算結(jié)果傳遞到應(yīng)用層需要 IO 和內(nèi)存拷貝開(kāi)銷(xiāo)赛蔫，即使硬件計(jì)算性能非常好，上層的同步等待和 IO 開(kāi)銷(xiāo)也會(huì)導(dǎo)致整體性能達(dá)不到預(yù)期泥张，無(wú)法充分利用硬件加速卡的計(jì)算能力呵恢。
6. 維護(hù)性差。硬件驅(qū)動(dòng)及應(yīng)用層 API 大部分是由安全廠家提供媚创，出現(xiàn)問(wèn)題后還需要廠家跟進(jìn)渗钉。用戶無(wú)法掌握核心代碼，比較被動(dòng)钞钙。不像開(kāi)源的 openssl鳄橘，不管算法還是協(xié)議，用戶都能掌握芒炼。

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

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

1. 優(yōu)化 TLS 協(xié)議棧鲸湃，剝離最消耗 CPU 資源的計(jì)算，主要有如下部分：
   • RSA 中的加解密計(jì)算盅安。
   • ECC 算法中的公私鑰生成唤锉。
   • 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è)過(guò)程是異步非阻塞的欧引。

HTTPS ****安全配置

協(xié)議版本選擇

SSL2.0 早就被證明是不安全的協(xié)議了垮媒，統(tǒng)計(jì)發(fā)現(xiàn)目前已經(jīng)沒(méi)有客戶端支持 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 目前為止沒(méi)有發(fā)現(xiàn)安全漏洞浪漠，建議優(yōu)先支持陕习。

加密套件選擇

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

1. 非對(duì)稱密鑰交換算法。建議優(yōu)先使用 ECDHE址愿，禁用 DHE该镣，次優(yōu)先選擇 RSA。
2. 證書(shū)簽名算法响谓。由于部分瀏覽器及操作系統(tǒng)不支持 ECDSA 簽名损合，目前默認(rèn)都是使用 RSA 簽名，其中 SHA1 簽名已經(jīng)不再安全娘纷，chrome 及微軟 2016 年開(kāi)始不再支持 SHA1 簽名的證書(shū) (http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)嫁审。%E3%80%82)
3. 對(duì)稱加解密算法。優(yōu)先使用 AES-GCM 算法失驶，針對(duì)0 以上協(xié)議禁用 RC4（ rfc7465）土居。
4. 內(nèi)容一致性校驗(yàn)算法。Md5 和 sha1 都已經(jīng)不安全嬉探，建議使用 sha2 以上的安全哈希函數(shù)。

HTTPS ****防攻擊

防止協(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é)議上岗。

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

重新協(xié)商（tls renegotiation）分為兩種：加密套件重協(xié)商 (cipher suite renegotiation) 和協(xié)議重協(xié)商（protocol renegotiation）福荸。
重新協(xié)商會(huì)有兩個(gè)隱患：

1. 重協(xié)商后使用弱的安全算法。這樣的后果就是傳輸內(nèi)容很容易泄露肴掷。
2. 重協(xié)商過(guò)程中不斷發(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é)商。