微信小程式存取的困境
農曆新年將至，微信小程式也如期發布，開發者在存取微信小程式過程中，會遇到以下問題：
小程式要求必須透過HTTPS 完成與服務端通信，若開發者選擇自行搭建HTTPS 服務，那需要自行SSL 憑證申請、部署，完成https 服務搭建，效率低流程冗長;且HTTPS 的SSL 加解析，對伺服器的CPU 有極大的開銷。
不只是小程序，蘋果 iOS 平台，Google Android 在 2017 也逐步強制要求開發者使用 HTTPS 存取。 HTTPS 似乎是個繞不開的門檻，讓不少開發者頭痛不已。
針對以上問題，騰訊雲端的負載平衡服務(cloud load balance)，希望透過對HTTPS 的效能最佳化，提供一鍵式的SSL 憑證申請服務，降低HTTPS 的應用門檻和使用成本，讓開發者能快速接取微信小程式等服務。首先，先讓我們來看看 HTTP 與 HTTPS 的對比，逐一解開您的謎團。
二、為什麼要存取 HTTPS—HTTP 的安全風險
HTTP 協定是一個非常簡單且有效率的協議，網路大部分的主流應用預設都是使用的HTTP。由於效能和上個世紀90 年代使用環境的限制，HTTP 協議本身並不是一個為了安全設計的協議，既沒有身份認證，也沒有一致性檢驗，最頭疼的是，HTTP 所有的內容都是明文傳輸的。
另一方面，網路的發展也是日新月異，各種 HTTP 應用不斷滲透到人們生活的各個層面。不管是社交、購物、金融、遊戲、還是搜索，這些 HTTP 服務都能帶給人們極大的便捷，提升生活品質和效率。
顯然，HTTP 和人們生活和經濟利益密切相關，遺憾的是，它不安全。也就意味著這裡一 定潛藏著巨大的安全隱憂。這些隱憂又集中表現在以下兩方面：
1、隱私外洩
由於 HTTP 本身是明文傳輸，用戶和服務端之間的傳輸內容都能被中間者查看。也就是說 你在網路上搜尋、購物、造訪的網點、點擊的頁面等信息，都可以被「中間人」取得。由於國人大多不太重視隱私的保護，這裡的風險較為隱性，傷害後果也不太好定量評估。已知的一些較嚴重的隱私外洩事件包括：
QQ 登陸態被不法份子竊取，然後在異地登陸，進行廣告和詐欺行為。
用戶手機號碼和身分資訊外洩。
用戶網路行為外洩。例如搜尋了一所醫院，很快就會有人打電話進行推廣(非效果廣告)。
2、頁面劫持
隱私外洩的風險比較隱蔽，使用者基本上感知不到。但另一類劫持的影響就非常明顯非常直接了──頁面劫持，也就是直接竄改使用者的瀏覽頁面。有很多頁面劫持很簡單粗暴，直接插入第三方廣告或運營商的流量提示資訊。
但也有一些劫持做得比較隱蔽，例如下面的京東頁面劫持：其中上圖是使用HTTP 方面的頁面，頂部箭頭所示的地方出現了一個購物推薦，很逼真，就像京東或瀏覽器官方的工具。
但換成 HTTPS 訪問，就沒有這個工具頁面，顯然是被劫持了。
3、劫持路徑及分類
那劫持到底是如何產生的呢？從技術上來講比較簡單，在內容經過的地方進行監聽竄改就行了。但要把整個劫持的產業鏈摸清楚，需要深入黑產內部，比較困難。有一點可以肯定的是，劫持大部分都是在中間的網路節點發生的，又叫「中間人」(MITM， man in the middle)。如下圖所示：
由於資訊傳輸都需要經過上述的「中間人節點」，它們又擁有資訊的讀寫權限，如果資訊沒有加密，也沒有校驗，那麼想要查看隱私，篡改頁面，對於「中間人」來說可謂是輕而易舉。
那劫持又有哪些主要的分類呢?根據劫持路徑劃分的話，主要是下圖所示的三類：
DNS 劫持，客戶端劫持和連結劫持。 根據我們的不完全統計，業務遇到的絕大部分劫持 (90%)都屬於連結劫持。
三、HTTPS 是解決連結劫持的核武
HTTPS 為什麼能很好的解決連結劫持呢？主要是三大武器:
1、身分認證—防假冒，防抵賴
每次建立一個全新的HTTPS 連線時，都需要對身分進行認證，確保使用者存取的是正確的目的網站。
2、內容加密—防竊聽
內容加密意義端對端的通訊內容全都是密文，中間人無法直接查看到明文，HTTPS 所有的應用層內容都是透過對稱加密來實現加密和解密的。
3、一致性校驗—防篡改
透過對資料和共享金鑰的MAC 碼來防止中間者篡改訊息內容，確保數據的一致性。
四、HTTPS 普及之痛
事實上 HTTPS 1995 年就誕生了，是一個非常古老、成熟的協定。同時又能很好地防止內容劫持，保護用戶隱私。但為什麼一直到今天，還有大部分的網站不支援HTTPS，只使用HTTP 呢?
#影響HTTPS 普及的主要原因可以概括為兩個字：「慢”和“貴”。
1、慢
在未經任何最佳化的情況下，HTTPS 會嚴重降低使用者的存取速度。主要因素包括:
網路耗時。由於協定的規定，必須要進行的網路傳輸。例如 SSL 完全握手，302 跳轉等。最壞情況下可能要增加 7 個 RTT。
計算耗時。無論是客戶端還是服務端，都需要進行對稱加解密，協定解析，私鑰計算，憑證校驗等計算，增加大量的計算時間。
2、貴
HTTPS 的貴，主要體現在如下三：
伺服器成本。 HTTPS 的私鑰運算會導致服務端效能的急遽下降，甚至不到HTTP 協定的十分之一，也就是說，如果HTTP 的效能是10000cps，HTTPS 的效能可能只有幾百cps，會增加數倍甚至數十倍的伺服器成本。
憑證成本。根據證書個數及證書類型，一年可能需要花費數百到數百萬不等的證書成本。
開發和維運成本。 HTTPS 協定比較複雜，openssl 的開源實作也常發生安全性BUG， 包括協定的配置，憑證的更新，過期監控，客戶端的相容等一系列問題都需要具備專業背景的技術人員跟進處理。
五、騰訊雲負載平衡器HTTPS 的效能最佳化
騰訊雲負載平衡器深針對HTTPS 推廣應用過程中的痛點進行了深度最佳化。接下來我們詳細介紹下這些優化方案：
1、訪問速度的優化
前文提到HTTPS 非常慢，我們也主要從兩個層面對訪問速度進行了優化：協定棧和前後端資源。
全連結協定堆疊最佳化
HTTPS 可以認為是HTTP over SSL，而HTTPS 又是使用TCP 協定進行傳輸，所以整個協定棧的最佳化涉及到三個層次:
TCP 最佳化。包括擁塞視窗的調整，tcp fast open，reuseport 的支持，最新的 BBR 擁塞控制演算法的支援等。
SSL 協定最佳化。分佈式 session cache, session ticket，False start, ocsp stapling file， 動態 record size 等。
SSL 協定優化最重要的目標還是提升簡化握手的比例。騰訊雲端透過實現全域 session cache 和全域 session ticket 來提升 SSL 的簡化握手比例，節省使用者存取時間和運算資源。
應用層協定最佳化。同時支援 SPDY，HTTP2，HSTS 等。
HTTP2 比起HTTP1.X 最大的優勢就是多路復用，能夠將多個HTTP 請求透過一個TCP 連接並行發送，相較於HTTP1.X 的串列發送，效能無疑是提升很多。
由於 HTTP2 是從 SPDY 繼承發展出來的，所以部分較老的客戶端只支援 SPDY，不支援 HTTP2。而大部分新客戶端，只支援 HTTP2，不支援 SPDY。為了同時相容於新舊客戶端的效能，騰訊雲同時支援 SPDY 和 HTTP2，最大化提升新舊版客戶端的效能。
前後端最佳化
HTTP2 及 SPDY 最大的特性與優點就是多工，能夠將多個請求透過一個連線並行發送出來。這個特性雖然很強大，但是如果也使用傳統的 HTTP 最佳化策略，多路復用的效果會很有限。例如網域分片，pipline 等都會影響多重化的效果。於是我們又透過多次的資料實驗，調整了一些前端資源包含後端存取的策略：
網域收歸。透過頁面資源及效能分析，確實網域收歸方案，例如行動頁面不超過 3 個。
預建連接。 STGW 提供預先連接頁面，透過對熱點頁面的使用者行為進行分析，提前建立連接，減少協定開銷對使用者體驗的影響。
透過騰訊雲遍佈全球的 CDN 及 IDC 節點就近完成 HTTPS 卸載。
2、運算效能最佳化
針對HTTPS 的運算效能，騰訊雲主要從三個層面進行了最佳化，包括:
盡量減少完全握手的發生，提升簡化握手比例。例如前文提到的全域 sessioncache 和 session ticket。
對於不可避免的完全握手，騰訊雲端實現了 RSA 非同步代理運算，透過對協定堆疊的改造和 SSL 硬體加速卡的使用，大幅提升了 HTTPS 的運算能力和防攻擊能力。
對稱加密計算過程也進行了場景使用上的最佳化。
以下再詳細介紹一下：
RSA 非同步代理運算
騰訊雲針對HTTPS 效能消耗最嚴重的環節－非對稱金鑰交換演算法進行了重點優化。最佳化思路主要包括如下三部分:
#演算法分離。就是將最消耗 CPU 資源的演算法剝離出來，不讓消耗本地的 CPU 資源。
代理計算。使用空閒的 CPU 機器或專門的 SSL 硬體加速卡來完成 RSA 計算。
非同步執行。傳統的 openssl 在進行 RSA 的時候，上層應用，例如 NGINX 都需要同步等待。這步驟也非常影響，必須要進行非同步改造，這樣在加速叢集進行 RSA 運算的時候，接取伺服器也可以接入其他使用者的請求，提升吞吐能力。
透過對 openssl 握手協定堆疊的深度改造以及 SSL 硬體加速卡的 RSA 運算效能，騰訊雲端 CLB 的 SSL 運算能力提升了 350%。單機 ECDHE_RSA 處理性能達到了 65000 cps。
對稱加密演算法的自動最優選擇
騰訊雲根據應用場景匹配最優的對稱加密演算法:
對於視訊等串流內容，優先使用aes- gcm。
針對不支援 aes-ni 硬體加速指令的行動終端，使用 chacha20-poly1305 。
針對 IE6 等古董等級的客戶端，使用 RC4 演算法。
3、協定的平行卸載
騰訊雲 CLB 支援現在主流的全部 HTTP 類別協定存取和卸載。包括：
http1.0/http1.1
http2 及前身spdy3.1
#https,包括ssl3.0, tlsv1.0,tlsv1.1,tlsv1. 2
websocket 及secure websocket。
tcp,udp 透明轉送。
CLB 能夠將上述七層協定統一轉換成 HTTP1.1，透傳給業務。對業務的好處也非常明顯: 0 開發成本就能使用 HTTPS 和 HTTP2，大大減少了適配各種協定和客戶端的壓力。
4、安全性
安全性涉及的領域和場景非常龐大，HTTPS 雖然能夠徹底解決鏈路劫持，但是對於以下兩類問題卻無能為力:
CC 攻擊，特別是HTTPS 計算型攻擊，HTTPS 的性能會急劇降低，引入更大的安全風險。
業務安全，包括 SQL 注入，XSS 跨站、網站掛馬等。
上述兩類都是經常困擾業務的風險極大的安全問題。
針對上述問題，騰訊雲也設計實現了一套針對 HTTPS 的防 CC 和 WAF 的安全系統，能夠有效地防禦這類安全風險。
Keyless（無金鑰載入）私鑰的重要性
#對憑證稍微熟悉的朋友都知道，SSL 金鑰和憑證都是成對使用的，一個憑證一定唯一對應一個私鑰。整個 HTTPS 最重要的一個資料就是 SSL 的私鑰了，如果私鑰洩露，整個握手過程就可以被劫持，簽章可以被偽造，對稱金鑰也可以被破解。整個 HTTPS 就毫無安全可言。
傳統的私鑰使用方案和風險
傳統的私鑰方案就是將私鑰和應用程式綁定在一起。例如大家熟知的 nginx, apache，如果想使用 HTTPS，必須在部署 nginx 的接取機器上部署相關的憑證和私密金鑰。
這種方案會有以下安全性上的問題：私鑰部署在雲端或 CDN，如果洩漏了怎麼辦？
無秘鑰方式
雖然騰訊雲的內網非常安全，但是出於對客戶的安全負責，徹底打消用戶對私鑰洩露的顧慮，確保用戶對私鑰的絕對控制，騰訊雲端提供一種無私鑰的載入方案。這個方案核心是「不需要把私鑰儲存在騰訊雲，允許用戶使用自己的伺服器保管私鑰，完成 HTTPS 的存取」。 騰訊雲端完全接觸不到私鑰，客戶甚至可以把私鑰放在家裡的伺服器上。
它的存取過程如下：
使用者發起 HTTPS 握手請求。
在涉及私鑰運算的時候，騰訊雲端 CLB 會將這個私鑰運算請求通過加密的自訂協議，轉發給用戶自己的 keyless 伺服器上。
keyless 服務呼叫使用者的私鑰完成計算。
keyless 服務將運算結果傳回給騰訊雲端 CLB。
CLB 繼續進行 HTTPS 請求的處理。
整個過程，騰訊雲接觸不到HTTPS 私鑰，需要注意一點的，keyless server 是騰訊雲提供一個服務端程序，代碼開源，用戶自主部署，服務端行為用戶掌握得一清二楚。
六、零門檻，HTTPS 快速存取微信小程式
騰訊雲端CLB 負載平衡器透過對協定棧及服務端的深度優化，實現了HTTPS 性能的巨大提升。同時，我們也透過與國際上著名的證書機構合作，大幅降低了證書的成本。騰訊雲CLB 在以下幾個方面，能夠為微信小程式存取帶來非常顯著的收益：
提供一鍵式的SSL 憑證申請，CLB 負載平衡服務作為HTTPS 代理，減輕開發負擔，讓開發者可以專注於小程式業務的開發。
使用 HTTPS 並不會降低 client 端的存取速度。 HTTP、HTTPS 存取時延幾乎一致。
叢集內單一伺服器 SSL 加解密效能，高達 6.5Wcps 的完全握手。相較於高效能CPU 提升了至少 3.5 倍，節省了服務端成本，並大幅提升了業務營運及流量突漲時的服務能力， 增強了運算型防攻擊的能力。
支援多種協定卸載及轉換。減少業務適配客戶端各種協定的壓力，業務後端只需要支援 HTTP1.1 就能使用 HTTP2，SPDY，SSL3.0，TLS1.2 等各版本協定。滿足微信小程序，iOS 平台等對協議的要求。
SSL 憑證申請、監控、替換。我們和國際頂尖的證書廠商 comodo，symantec 已有深入合作，服務體系完善。
防 CC 及 WAF 功能。能夠有效杜絕慢連線、高頻定點攻擊、SQL 注入、網頁掛馬等應用層攻擊。
以上的這些收益，可以幫助開發者降低 HTTPS 的試用門檻。
更多小程式開發者需要關注HTTPS 協定深度解析相關文章請關注PHP中文網！
