你的流量加密尚需功能再升級

當今互聯網世界安全形勢嚴峻，內容篡改、流量劫持、我的隱私信息泄露等事件層出不窮。爲讓廣大用戶能夠更安全的使用互聯網服務，加密流量的應用愈來愈普遍，其地位也日益重要。在互聯網領域，使用最多的流量加密技術就是HTTPS。現在互聯網正在經歷從明文（HTTP）到加密（HTTPS）的轉變。

HTTPS使互聯網環境更安全的同時，也帶來了不少額外挑戰，例如：加密運算消耗更多的CPU資源，這意味着服務器端須要增長更多的硬件（通常而言，HTTPS的硬件成本是同性能HTTP服務的3倍以上）；而在移動客戶端，如手機、平板電腦等環境中，這則意味着消耗更多電池電量。此外，HTTPS在握手階段引入額外RTT，加上加解密運算的額外時間開銷，增長了HTTP請求的時延，極大的影響了用戶體驗。

爲應對上述挑戰，HTTPS尚需功能升級，白山研發團隊率先進行嘗試，新增：TLS1.3協議、RSA多素數支持、ChaCha20算法支持及HTTPS可視化運營等特性，具體以下圖：

1、TLS 1.3協議——更低時延、更安全

TLS 1.3協議依循極簡主義的設計哲學，祛除並修復了舊版本中的壞味道，將密鑰交換、對稱加解密、壓縮等環節中可能存在的安全隱患剔除出該版本，包括：

• TLS 1.3協議中選取的密鑰交換算法均支持前向安全性，廢除了RSA祕鑰交換和靜態DH密鑰交換等不支持前向安全性的算法；
• DSA證書做爲歷史遺留產物，還沒有被大規模使用過，加之安全性較差，故在TLS 1.3協議中被廢棄；
• 禁用自定義的DH組參數，防止受到Key Recovery Attack攻擊；
• 禁用CBC模式，經實踐證實這種對稱加密模式尚存在安全隱患；
• 禁用RC4流加密算法：2013年，英國皇家哈洛威學院的研究人員發現一種針對TLS的攻擊，可從RC4算法加密的密文中恢復出少許明文；
• 禁用SHA1摘要算法：2017年初Google與荷蘭研究機構CWI Amsterdam共同宣佈已破解SHA1；
• 禁用出口密碼套件：2000年美國放寬密碼出口管制，隨後出現的FREAK和LogJam攻擊，能夠經過中間人將加密套件降級成出口套件，進而將數據破解；
• 禁用TLS壓縮：TLS壓縮存在安全漏洞，攻擊者經過漏洞能夠實行會話劫持並發動進一步攻擊；
• 加密握手消息：TLS1.3協議規定在ServerHello消息後的握手信息須要加密。TLS1.2及以前版本的協議中各類擴展信息在ServerHello中以明文方式發送，在新版本中可在加密以後封裝到EncryptedExtension消息中，在ServerHello消息後發送，增長數據安全性。
  HTTPS提升網絡安全的同時也增長了額外的性能消耗，如：額外的SSL握手交互過程，數據加解密對CPU的消耗等。TLS1.3在提升效率方面進行了大量改進，特別是對SSL握手過程從新設計，將握手的交互延時從2-RTT下降爲1-RTT甚至是0-RTT。在網絡環境較差或節點距離較遠的狀況下，這種優化可節省幾百毫秒的時間。這幾百毫秒就能決定用戶下一步的行爲是繼續瀏覽仍是關閉。性能提高包括：
• 1-RTT握手機制：以ECDHE密鑰交換過程爲例，握手過程以下。將客戶端發送ECDH臨時公鑰的過程提早至ClientHello ，同時刪除ChangeCipherSpec協議簡化握手過程，使第一次握手只須要一個RTT。
  

• 0-RTT握手機制：爲使TLS協議性能獲得極致提高，TLS 1.3提出了0-RTT的握手機制。對於用戶最近訪問過的網站，可在第一次交互時就向服務器發送加密數據。具體實現過程以下：客戶端和服務端經過TLS session複用或外部輸入的方式共享PSK，這種狀況下容許客戶端在第一次交互的ClientHello消息中包含使用PSK加密的應用數據。

爲展示更加直觀的效果，白山搭建了支持TLS 1.3協議的服務器。

對應當前主流瀏覽器支持的draft-18的服務器：https://tls13.baishancloud.com/
對應最新的draft-21版本的服務器：https://tls13.baishancloud.com:44344

2、RSA多素數——更快、更穩定

簡單來講，多素數RSA是指在生成RSA密鑰的時候，在計算固定長度（好比2048位或者4096位）的模數（modulus）的時候，選擇多於2個素數並進行相乘獲得最終指望長度的modulus。也就是說，n = pq 這種標準RSA的計算方式n = pq ，在多素數RSA中，會變成 n = r1r2r3r4r5... 的形式。這也是多素數（multi-prime RSA）這個名字的由來。

這樣作的好處是能夠大幅提升RSA私鑰計算性能（下降握手時間，減輕服務器壓力），具體數據見下圖：

由上可知，多素數RSA具有三個特色：

素數個數越多，單個RSA私鑰運算所需時間越短，總體性能越高；
其中：

• 3素數相對標準RSA提升25%
• 5素數提升230%
• 8素數提升310%
• 15素數提升近400%

素數個數越多，RSA密鑰生成時間越短；

素數個數越多，安全強度越差，私鑰被破解的可能性越高

多素數RSA最大優點在於做爲一種不須要使用硬件加速卡的低成本方案，能夠在某些安全性要求不高的場景下發揮做用。例如：靜態圖片對安全強度的要求不如動態數據大，可考慮採用多素數RSA方案。

當前OpenSSL對多素數RSA並不支持，白山基於 RFC 8017 在OpenSSL中實現多素數RSA功能，並將其開源，開源代碼位於：https://github.com/openssl/op... 目前正向OpenSSL官方合併代碼，有望歸入OpenSSL 1.1.1版本的發佈。

3、ChaCha20算法——更省電

ChaCha20是Google大力推廣的一種對稱加密算法，用於解決不支持AES硬件加速指令的Android設備的HTTPS性能問題。Google在其Chrome瀏覽器中增長了對這一算法的支持，同時還支持Poly1305摘要算法，造成了ChaCha20-Poly1305組合，並在2015年和2016年將這組算法標準化，造成 RFC 7539 和 RFC 7905 兩篇RFC文檔。

在對稱加密領域，自從AES算法從性能上超越並取代3DES算法，成爲NIST指定的加密算法後，再未出現其餘普遍使用而且兼顧性能和安全的對稱加密算法。這帶來了如下幾個問題：

1. 將來若是AES被發現存在問題，人們將不得不退而使用老舊的3DES算法，所以業界須要一個備選算法；
2. 在不支持AES硬件加速指令的設備上，AES算法的性能不具有明顯優點（尤爲是和某些流加密算法相比）；
3. AES若是實現的不正確，可能存在緩存碰撞時序攻擊（AES Cache-Collision Timing Attack）。

而ChaCha20能夠較好的解決上述問題。

ChaCha20是一種流加密算法，實現較爲簡單，而且比純軟件實現的AES性能更好。

性能對比

上圖是在不使用AES硬件加速的狀況下，對AES和ChaCha20進行的性能對比測試。其中ChaCha20性能是GCM模式AES256的5倍左右。

將ChaCha20同已經瀕臨滅絕的RC4算法進行了對比，同爲流加密算法，ChaCha20的性能達到了RC4的2倍之多。單位時間內運算次數的提升，表示單次操做所需的指令週期更短，而在移動端設備上這種特色直接影響電池電量的消耗。

雖然在HTTPS的場景中，一次全握手產生的功耗要遠大於對稱加密環節產生的，可是在針對大文件加密、解密操做時，更快的對稱加密算法依然存在實際應用價值。

但若是設備已經支持AES硬件加速指令，例如iPhone和部分Android系統手機或支持AES-NI指令的Intel CPU等，AES的速度依然具備絕對優點：

由上圖可見，其性能約爲ChaCha20的3倍左右，此外GCM模式的AES比CBC模式在有硬件加速的狀況下性能提高的更大，這主要是因爲GCM模式能夠比CBC模式能更好利用硬件流水線進行併發。

HTTPS服務全面支持ChaCha20-Poly1305算法，能夠同時採用自動適應客戶端算法列表的處理手段：

1. 若是客戶端不支持AES硬件加速指令，則優先使用ChaCha20
2. 不然按照服務器的算法優先級順序選擇AES算法
   目前白山支持的TLS加密套件有：
3. TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
4. TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
5. TLS_CHACHA20_POLY1305_SHA256 (TLSv1.3用）

結合以上ChaCha20的性能對比，能夠認爲該算法最適合在不支持AES硬件加速的Android平臺中使用。所以做爲應用程序，最好能夠判斷當前運行的平臺是否支持AES指令。如不支持，則將上述TLS加密套件排列在客戶端ClientHello消息中最前的位置（根據支持的協議），根據客戶端支持的加密套件列表選擇最優算法來和客戶端握手。在支持AES指令的硬件平臺上，推薦優先選擇AES-GCM算法；而CBC模式的RSA和RC4算法在不少狀況下並不是最好選擇，應當儘可能避免過多使用。

4、HTTPS可視化運營——更直觀

HTTPS的數字化運營在HTTPS服務的質量監控、服務優化等方面有着舉足輕重的做用。

目前白山數字化運營平臺對主要關注以下幾點：

• HTTPS請求數：可直接觀察當前網站的活躍程度，提供用戶行爲的參考依據；
• HTTPS握手時間統計： 透明化展現握手階段的時間消耗，同時增長對該耗時的監控，握手時間超過閾值時能快速感知並處理，最大程度保障用戶體驗；
• HTTPS握手複用率統計：複用表示客戶端可直接複用上次與服務端協商獲得的密鑰。複用率高則表示HTTPS的握手階段消耗低；當複用率處於較低的水平時，則須要及時調整複用策略；
• 協議分佈（主要指SSL/TLS的協議版本）：經過大數據分析獲得協議分佈狀況。大量客戶端使用低版本協議發起請求可能意味着異常狀況。爲提供更好的HTTPS服務，還需關注更加細緻的狀態參數：
• 加密算法分佈：HTTPS服務質量必定程度上取決於加密算法的性能，經過對加密算法統計分析，可有效指導算法優化。例如：90%以上的HTTPS握手會使用RSA算法，白山針對該算法開發多素數RSA功能，並提交到OpenSSL社區，提升了RSA算法效率；
• 客戶端分佈：不一樣客戶端可能針對不一樣算法有相應的優化，例如ChaCha20在不支持AES硬件加速的Android平臺中有比較好的性能，可根據客戶端分佈狀況預判該算法優化效果。另外當產生新的安全漏洞，須要升級或廢棄SSL/TLS的某些特性時，須要綜合該信息判斷影響範圍。例如：某些特性的停用會致使部分舊版本客戶端沒法訪問，就能夠經過分析這類客戶端佔比來決定如何處理。

如下是可視化運營平臺截圖：