轉：HTTPS 協議

做者簡介：羅成 騰訊雲資深研發工程師

1、微信小程序接入的困境

農曆新年將至，微信小程序也如期發佈，開發者在接入微信小程序過程當中，會遇到如下問題：

小程序要求必須經過 HTTPS 完成與服務端通訊，若開發者選擇自行搭建 HTTPS 服務，那須要自行 SSL 證書申請、部署，完成 https 服務搭建，效率低流程冗長;且 HTTPS 的 SSL 加解析，對服務器的 CPU 有極大的開銷。

不只僅是小程序，蘋果 iOS 平臺，Google Android 在 2017 也逐步強制要求開發者使用 HTTPS 接入。HTTPS 彷佛是一個繞不開的門檻，讓很多開發者頭痛不已。

針對以上問題，騰訊雲的負載均衡服務(cloud load balance)，但願經過對 HTTPS 的性能優化，提供一鍵式的 SSL 證書申請服務，下降 HTTPS 的應用門檻和使用成本，讓開發者能快速接入微信小程序等服務。首先，先讓咱們看看 HTTP 與 HTTPS 的對比，逐一解開您的謎團。

2、爲何要接入 HTTPS—HTTP 的安全風險

HTTP 協議是一個很是簡單和高效的協議，互聯網大部分的主流應用默認都是使用的HTTP。因爲性能和上個世紀 90 年代使用環境的限制，HTTP 協議自己並非一個爲了安全設計的協議，既沒有身份認證，也沒有一致性檢驗，最頭疼的是，HTTP 全部的內容都是明文傳輸的。

另一方面，互聯網的發展也是突飛猛進，各類 HTTP 應用不斷地滲透到人們生活的方方面面。無論是社交、購物、金融、遊戲、仍是搜索，這些 HTTP 服務都能帶給人們極大的便捷，提高生活質量和效率。

顯然，HTTP 和人們生活及經濟利益密切相關，遺憾的是，它不安全。也就意味着這裏一 定潛藏着巨大的安全隱患。這些隱患又集中表如今以下兩方面：

一、隱私泄露

因爲 HTTP 自己是明文傳輸，用戶和服務端之間的傳輸內容都能被中間者查看。也就是說 你在網上搜索、購物、訪問的網點、點擊的頁面等信息，均可以被「中間人」獲取。因爲國人大多不過重視隱私的保護，這裏的風險比較隱性，傷害後果也不太好定量評估。已知的一些比較嚴重的隱私泄露事件包括：

1. QQ 登錄態被不法分子竊取，而後在異地登錄，進行廣告和欺詐行爲。
2. 用戶手機號和身份信息泄露。
3. 用戶網上行爲泄露。好比搜索了一所醫院，很快就會有人打電話進行推廣(非效果廣告)。

二、頁面劫持

隱私泄露的風險比較隱蔽，用戶基本感知不到。但另一類劫持的影響就很是明顯很是直接了——頁面劫持，也就是直接篡改用戶的瀏覽頁面。有不少頁面劫持很簡單粗暴，直接插入第三方廣告或者運營商的流量提示信息。

但也有一些劫持作得比較隱蔽，好比下面的京東頁面劫持：其中上圖是使用 HTTP 方面的頁面，頂部箭頭所示的地方出現了一個購物推薦，很逼真，就像京東或者瀏覽器官方的工具。

但換成 HTTPS 訪問，就沒有這個工具頁面，顯然是被劫持了。

三、劫持路徑及分類

那劫持究竟是如何產生的呢？從技術上來說比較簡單，在內容通過的地方進行監聽篡改就好了。但要想把整個劫持的產業鏈條摸清楚，須要深刻黑產內部，比較困難。有一點能夠確定的是，劫持大部分都是在中間的網絡節點發生的，又叫「中間人」(MITM， man in the middle)。以下圖所示：

因爲信息傳輸都須要通過上述的「中間人節點」，它們又擁有信息的讀寫權限，若是信息沒有加密，也沒有校驗，那麼想要查看隱私，篡改頁面，對於「中間人」來講可謂是垂手可得。

那劫持又有哪些主要的分類呢?根據劫持路徑劃分的話，主要是下圖所示的三類：

DNS 劫持，客戶端劫持和鏈路劫持。 根據咱們的不徹底統計，業務遇到的絕大部分劫持 (90%)都屬於鏈路劫持。

3、HTTPS 是解決鏈路劫持的核武器

HTTPS 爲何能很好的解決鏈路劫持呢？主要是三大武器:

一、身份認證—防假冒，防抵賴

每次創建一個全新的 HTTPS 鏈接時，都須要對身份進行認證，確保用戶訪問的是正確的目的網站。

二、內容加密—防竊聽

內容加密意味端對端的通訊內容全都是密文，中間人沒法直接查看到明文，HTTPS 全部的應用層內容都是經過對稱加密來實現加密和解密的。

三、一致性校驗—防篡改

經過對數據和共享密鑰的 MAC 碼來防止中間者篡改消息內容，確保數據的一致性。

4、HTTPS 普及之痛

事實上 HTTPS 1995 年就誕生了，是一個很是古老、成熟的協議。同時又能很好地防止內容劫持，保護用戶隱私。可是爲何一直到今天，還有大部分的網站不支持 HTTPS，只使用 HTTP 呢?

影響 HTTPS 普及的主要緣由能夠歸納爲兩個字：「慢」和「貴」。

一、慢

在未經任何優化的狀況下，HTTPS 會嚴重下降用戶的訪問速度。主要因素包括:

1. 網絡耗時。因爲協議的規定，必需要進行的網絡傳輸。好比 SSL 徹底握手，302 跳轉等。最壞狀況下可能要增長 7 個 RTT。

1. 計算耗時。不管是客戶端仍是服務端，都須要進行對稱加解密，協議解析，私鑰計算，證書校驗等計算，增長大量的計算時間。

二、貴

HTTPS 的貴，主要體如今以下三方面：

1. 服務器成本。HTTPS 的私鑰計算會致使服務端性能的急劇降低，甚至不到 HTTP 協議的十分之一，也就是說，若是 HTTP 的性能是 10000cps，HTTPS 的性能可能只有幾百 cps，會增長數倍甚至數十倍的服務器成本。
2. 證書成本。根據證書個數及證書類型，一年可能須要花費幾百到幾百萬不等的證書成本。
3. 開發和運維成本。HTTPS 協議比較複雜，openssl 的開源實現也常常發生安全BUG， 包括協議的配置，證書的更新，過時監控，客戶端的兼容等一系列問題都須要具有專業背景的技術人員跟進處理。

5、騰訊雲負載均衡器 HTTPS 的性能優化

騰訊雲負載均衡器深針對 HTTPS 推廣應用過程當中的痛點進行了深度優化。接下來咱們詳細地介紹下這些優化方案：

一、訪問速度的優化

前文提到 HTTPS 很是慢，咱們也主要從兩個層面對訪問速度進行了優化： 協議棧和先後端資源。

全鏈路協議棧優化

HTTPS 能夠認爲是 HTTP over SSL，而 HTTPS 又是使用 TCP 協議進行傳輸，因此整個協議棧的優化涉及到三個層面:

1. TCP 優化。包括擁塞窗口的調整，tcp fast open，reuseport 的支持，最新的 BBR 擁塞控制算法的支持等。

1. SSL 協議優化。分佈式 session cache, session ticket，False start, ocsp stapling file， 動態 record size 等。

SSL 協議優化最重要的目標仍是提高簡化握手的比例。騰訊雲經過實現全局 session cache 和全局 session ticket 來提高 SSL 的簡化握手比例，節省用戶訪問時間和計算資源。

1. 應用層協議優化。同時支持 SPDY，HTTP2，HSTS 等。

HTTP2 相比 HTTP1.X 最大的優點就是多路複用，可以將多個 HTTP 請求經過一個 TCP 鏈接並行發送，相比 HTTP1.X 的串行發送，性能無疑是提高不少。

因爲 HTTP2 是從 SPDY 繼承發展出來的，因此部分較老的客戶端只支持 SPDY，不支持 HTTP2。而大部分新客戶端，只支持 HTTP2，不支持 SPDY。爲了同時兼容新老客戶端的性能，騰訊雲同時支持 SPDY 和 HTTP2，最大化提高新老版本客戶端的性能。

先後端優化

HTTP2 及 SPDY 最大的特性和優點就是多路複用，可以將多個請求經過一個鏈接並行發送出來。這個特性雖然很強大，可是若是還使用傳統的 HTTP 優化策略，多路複用的效果會頗有限。好比域名分片，pipline 等都會影響多路複用的效果。因而咱們又經過屢次的數據實驗，調整了一些前端資源包括後端接入的策略：

1. 域名收歸。經過頁面資源及性能分析，確實域名收歸方案，好比移動頁面不超過 3 個。
2. 預建鏈接。STGW 提供預鏈接頁面，經過對熱點頁面的用戶行爲進行分析，提早創建鏈接，減小協議開銷對用戶體驗的影響。
3. 經過騰訊雲遍及全球的 CDN 及 IDC 節點就近完成 HTTPS 卸載。

二、計算性能優化

針對 HTTPS 的計算性能，騰訊雲主要從三個層面進行了優化，包括:

1. 儘可能減小徹底握手的發生，提高簡化握手比例。好比前文提到的全局 sessioncache 和 session ticket。
2. 對於不可避免的徹底握手，騰訊雲實現了 RSA 異步代理計算，經過對協議棧的改造和 SSL 硬件加速卡的使用，大幅度提高了 HTTPS 的計算能力和防攻擊能力。
3. 對稱加密計算過程也進行了場景使用上的優化。

下面再詳細介紹一下：

RSA 異步代理計算

騰訊雲針對 HTTPS 性能消耗最嚴重的環節——非對稱密鑰交換算法進行了重點優化。優化思路主要包括以下三部分:

1. 算法分離。就是將最消耗 CPU 資源的算法剝離出來，不讓消耗本地的 CPU 資源。
2. 代理計算。使用空閒的 CPU 機器或者專門的 SSL 硬件加速卡來完成 RSA 計算。
3. 異步執行。傳統的 openssl 在進行 RSA 的時候，上層應用，好比 NGINX 都須要同步等待。這一步驟也很是影響，必需要進行異步改造，這樣在加速集羣進行 RSA 計算的時候，接入服務器也能夠接入其餘用戶的請求，提高吞吐能力。

經過對 openssl 握手協議棧的深度改造以及 SSL 硬件加速卡的 RSA 計算性能，騰訊雲 CLB 的 SSL 計算能力提高了 350%。單機 ECDHE_RSA 處理性能達到了 65000 cps。

對稱加密算法的自動最優選擇

騰訊雲根據應用場景匹配最優的對稱加密算法:

1. 對於視頻等流媒體內容，優先使用 aes-gcm。
2. 針對不支持 aes-ni 硬件加速指令的移動終端，使用 chacha20-poly1305 。
3. 針對 IE6 等古董級別的客戶端，使用 RC4 算法。

三、協議的並行卸載

騰訊雲 CLB 支持如今主流的所有 HTTP 類協議接入和卸載。包括：

1. http1.0/http1.1
2. http2 及前身 spdy3.1
3. https,包括 ssl3.0, tlsv1.0,tlsv1.1,tlsv1.2
4. websocket 及 secure websocket。
5. tcp,udp 透明轉發。

CLB 可以將上述七層協議統一轉換成 HTTP1.1，透傳給業務。對業務的好處也很是明顯: 0 開發成本就能使用 HTTPS 和 HTTP2，極大減小了適配各類協議和客戶端的壓力。

四、安全

安全涉及的領域和場景很是龐大，HTTPS 雖然可以完全解決鏈路劫持，可是對於以下兩類問題卻無能爲力:

1. CC 攻擊，特別是 HTTPS 計算型攻擊，HTTPS 的性能會急劇下降，引入更大的安全風險。
2. 業務安全，包括 SQL 注入，XSS 跨站、網站掛馬等。

上述兩類都是常常困擾業務的風險極大的安全問題。

針對上述問題，騰訊雲也設計實現了一套針對 HTTPS 的防 CC 和 WAF 的安全系統，可以有效地防護這類安全風險。

Keyless（無密鑰加載）

私鑰的重要性

對證書稍微熟悉的朋友都知道，SSL 密鑰和證書都是成對使用的，一個證書必定惟一對應一個私鑰。整個 HTTPS 最重要的一個數據就是 SSL 的私鑰了，若是私鑰泄露，整個握手過程就能夠被劫持，簽名能夠被僞造，對稱密鑰也能夠被破解。整個 HTTPS 就毫無安全可言。

傳統的私鑰使用方案和風險

傳統的私鑰方案就是將私鑰和應用程序綁定在一塊兒。好比你們熟知的 nginx, apache，若是想使用 HTTPS，必須在部署 nginx 的接入機器上部署相關的證書和私鑰。

這種方案會有以下安全上的問題： 私鑰部署在雲端或者 CDN，若是泄露了怎麼辦？

無祕鑰方式

雖然騰訊雲的內網很是安全，可是出於對客戶的安全負責，完全打消用戶對私鑰泄露的顧 慮，確保用戶對私鑰的絕對控制，騰訊雲提供一種無私鑰的加載方案。這個方案核心是 「不須要把私鑰存儲在騰訊雲，容許用戶使用本身的服務器保管私鑰，完成 HTTPS 的接入」。 騰訊雲徹底接觸不到私鑰，客戶甚至能夠把私鑰保存在本身家裏的服務器上。

它的接入過程以下：

1. 用戶發起 HTTPS 握手請求。
2. 在涉及到私鑰計算的時候，騰訊雲 CLB 會將這個私鑰計算請求經過加密的自定義協議，轉發給用戶本身的 keyless 服務器上。
3. keyless 服務調用用戶的私鑰完成計算。
4. keyless 服務將計算結果返回給騰訊雲 CLB。
5. CLB 繼續進行 HTTPS 請求的處理。

整個過程， 騰訊雲接觸不到 HTTPS 私鑰，須要注意一點的，keyless server 是騰訊雲提供一個服務端程序，代碼開源，用戶自主部署，服務端行爲用戶掌握得一清二楚。

6、零門檻，HTTPS 快速接入微信小程序

騰訊雲 CLB 負載均衡器經過對協議棧及服務端的深度優化，實現了 HTTPS 性能的巨大提高。同時，咱們也經過與國際上著名的證書機構合做，極大下降了證書的成本。騰訊雲 CLB 在以下幾個方面，可以爲微信小程序接入帶來很是顯著的收益：

1. 提供一鍵式的 SSL 證書申請，CLB 負載均衡服務做爲 HTTPS 代理，減輕開發負擔，讓開發者能夠專一小程序業務的開發。
2. 使用 HTTPS 並不會下降 client 端的訪問速度。HTTP、HTTPS 訪問時延幾乎一致。
3. 集羣內單臺服務器 SSL 加解密性能，高達 6.5Wcps 的徹底握手。相比高性能CPU 提高了至少 3.5 倍，節省了服務端成本，極大提高了業務運營及流量突漲時的服務能力， 加強了計算型防攻擊的能力。
4. 支持多種協議卸載及轉換。減小業務適配客戶端各類協議的壓力，業務後端只須要支持 HTTP1.1 就能使用 HTTP2，SPDY，SSL3.0，TLS1.2 等各版本協議。知足微信小程序，iOS 平臺等對協議的要求。
5. SSL 證書申請、監控、替換。咱們和國際頂級的證書廠商 comodo，symantec 已有深刻合做，服務體系完善。
6. 防 CC 及 WAF 功能。可以有效杜絕慢鏈接、高頻定點攻擊、SQL 注入、網頁掛馬等應用層攻擊。