如何在堅持原創、國產替代的同時，保持技術領先，以及遵循國際上最佳實踐？
該文主要貢獻（點選標題）
- 我們首次公開分析了 MMTLS 的安全性和隱私屬性，MMTLS 是微信使用的主要網路協議，微信是一款每月活躍使用者超過 10 億的應用程式。
- 我們發現 MMTLS 是 TLS 1.3 的修改版本，微信開發人員對加密技術所做的許多修改都引入了弱點。
- 進一步分析發現，早期版本的微信使用了一種安全性較低、定製設計的協議，其中包含多個漏洞，我們將其描述為“業務層加密”。在現代微信版本中，除了 MMTLS 之外，仍使用這一層加密。
- 雖然我們無法開發出一種能夠完全破解微信加密的攻擊方式，但其實現方式與十億使用者使用的應用程式中所期望的加密級別不一致，例如其使用確定性 IV 和缺乏前向保密性。
- 這些發現有助於進一步研究中國生態系統中的應用程式未能採用最佳加密實踐，而是選擇發明自己的、往往存在問題的系統。
- 我們將在配套的Github 儲存庫中釋出技術工具和有關我們技術方法的進一步文件。這些工具和文件以及本主要報告將幫助未來的研究人員研究微信的內部工作原理。
MMTLS 加密問題
1、確定性 IV
MMTLS 加密過程每次連線生成一個 IV。然後，它們會為該連線中加密的每個後續記錄增加 IV。通常，NIST建議不要在 AES-GCM 中使用完全確定性的 IV 派生，因為很容易意外重複使用 IV。在 AES-GCM 的情況下，重複使用 (key, IV) 元組是災難性的，因為它允許從 AES-GCM 身份驗證標籤中恢復金鑰。由於這些標籤附加到 AES-GCM 密文以進行身份驗證，因此可以從使用相同金鑰和 IV 對加密的少至 2 個密文中恢復明文。
此外，Bellare 和 Tackmann還表明，使用確定性 IV 可以讓強大的對手暴力破解特定的 (金鑰，IV) 組合。如果加密系統部署到非常大的（即網際網路大小）所選 (金鑰，IV) 組合池中，則這種型別的攻擊適用於強大的對手。由於微信擁有超過 10 億使用者，因此這種數量級使這種攻擊處於可行性範圍內。
2、缺乏前向保密
現代通訊協議通常都要求具有前向保密性，以降低會話金鑰的重要性。一般來說，TLS 本身在設計上就是前向保密性的，但“恢復”會話的第一個資料包除外。第一個資料包使用“預共享金鑰”或上次握手期間建立的 PSK 進行加密。
MMTLS 在設計上大量使用 PSK。由於 Shortlink 傳輸格式僅支援單次往返通訊（透過單個 HTTP POST 請求和響應），因此透過傳輸格式傳送的任何加密資料都使用預共享金鑰加密。由於洩露共享的 `PSK_ACCESS` 金鑰將使第三方能夠解密透過多個 MMTLS 連線傳送的任何 EarlyData，因此使用預共享金鑰加密的資料不是前向機密。透過 MMTLS 加密的絕大多數記錄都是透過 Shortlink 傳輸傳送的，這意味著微信傳送的大多數網路資料在連線之間不是前向機密。此外，在開啟應用程式時，微信會建立一個長壽命的 Longlink 連線。這個長壽命的 Longlink 連線在微信應用程式的持續時間內都是開啟的，任何需要傳送的加密資料都透過同一連線傳送。由於大多數微信請求要麼使用（A）會話恢復 PSK 或（B）長壽命 Longlink 連線的應用程式資料金鑰加密，因此微信的網路流量通常不會在網路請求之間保留前向保密性。
3、業務層加密問題
業務層加密結構，尤其是對稱模式 AES-CBC 結構本身存在許多嚴重問題。由於微信發出的請求是雙重加密的，這些問題隻影響內部業務層加密，因此我們沒有找到立即利用它們的方法。然而，在僅使用業務層加密的舊版微信中，這些問題是可以被利用的。
- 後設資料洩露：業務層加密不會對使用者ID、請求URI等後設資料進行加密，具體細節在“業務層請求”一節中提到。這個問題也被微信開發者們自己承認，也是開發MMTLS加密的動機之一。
- 可偽造的 genSignature 完整性檢查：可以偽造長度為evil_sig的簽名
- 分組密碼模式下金鑰、IV 重複使用：重複使用兩者意味著如果兩個明文相同，它們將加密為相同的密文。
- 加密金鑰問題：伺服器選擇客戶端使用的加密金鑰是非常不合常規的。事實上，我們注意到伺服器生成的加密金鑰（“會話金鑰”）僅使用可列印的 ASCII 字元。因此，即使金鑰長度為 128 位，該金鑰的熵也最多為 106 位。
為什麼業務層加密很重要？
既然業務層加密被包裹在 MMTLS 中，那麼它是否安全又有什麼關係呢？首先，從我們對微信早期版本的研究來看，業務層加密是微信網路請求的唯一加密層，直到 2016 年。
其次，從業務層加密暴露未加密的內部請求 URI 的事實來看，微信的可能架構之一是託管不同的內部伺服器來處理不同型別的網路請求（對應不同的“requestType”值和不同的 cgi-bin 請求 URL）。
例如，在前端微信伺服器（處理 MMTLS 解密）終止 MMTLS 後，轉發到相應內部微信伺服器的內部微信請求不會被重新加密，因此僅使用業務層加密進行加密。微信內聯網中的網路竊聽者或網路分路器可能會攻擊這些轉發請求上的業務層加密。
然而，這種情況純粹是推測性的。騰訊對我們披露的回應涉及業務層加密中的問題，並暗示他們正在慢慢從問題更大的 AES-CBC 遷移到 AES-GCM，因此騰訊也對此感到擔憂。
建議微信遷移到標準 QUIC 實現
TCP 和 TLS 握手都需要一次往返，這意味著傳送的每個新資料包都需要兩次往返。如今，TLS-over-QUIC 結合了傳輸層和加密層握手，只需要一次握手。QUIC 兼具兩全其美的優勢，既提供了強大的前向秘密加密，又將安全通訊所需的往返次數減少了一半。
除了網路效能之外，還有客戶端效能的問題。由於微信的加密方案對每個請求執行兩層加密，因此客戶端加密資料的工作量是使用單一標準化密碼系統的兩倍。
國產密碼技術在中國的應用趨勢
避免使用 TLS 並偏愛專有和非標準加密技術背離了加密最佳實踐。
隨著全球網際網路逐漸轉向使用 QUIC 或 TLS 等技術保護傳輸中的資料，這是一種日益增長且令人擔憂的趨勢，僅出現在中國安全領域。
反DNS劫持機制
和騰訊編寫自己的加密系統類似，我們發現在 Mars 中騰訊也編寫了一個專有的域名查詢系統。這個功能在 Mars 中被稱為“NewDNS”。根據我們的動態分析，這個功能在微信中經常使用。乍一看，NewDNS 重複了 DNS（域名系統）已經提供的功能，而 DNS 已經內建在幾乎所有聯網裝置中。
微信並不是中國唯一一款使用此類系統的應用程式。中國的主要雲端計算提供商（如阿里雲和騰訊雲）都提供自己的 DNS over HTTP 服務。
採用這種系統的一個可能原因是，中國的 ISP 經常實施DNS 劫持來插入廣告並重定向網路流量以進行廣告欺詐。這個問題非常嚴重，以至於六家中國網際網路巨頭於 2015 年發表聯合宣告，敦促 ISP 改進。
與 MMTLS 加密系統類似，騰訊的 NewDNS 域名查詢系統旨在滿足中國網路環境的需求。多年來，DNS 本身已被證明存在多個安全和隱私問題。
與 DNS 本身相比，NewDNS 是否存在更多或更少的問題仍是一個懸而未決的問題。我們將這個問題留待將來研究。
Mars STN 在微信之外的使用
微信之外對 Mars 的採用令人擔憂，因為 Mars 預設不提供任何傳輸加密。
基於以下觀察，我們推測 Mars（mars-open）在微信之外也有廣泛的應用：
- Mars GitHub 儲存庫中存在許多問題。
- 有大量 技術概述瞭如何使用 Mars 構建即時通訊系統。
- 目前已經有基於Mars的白標即時通訊系統產品。
Mars 的文件也比較缺乏。官方wiki上只有幾篇關於如何與 Mars 整合的舊文章。使用 Mars 的開發人員通常求助於在 GitHub 上提問。缺乏文件意味著開發人員更容易犯錯，最終降低安全性。
背景
公民實驗室是位於加拿大多倫多的多倫多大學蒙克全球事務與公共政策學院的一個學術研究小組。
- 該小組2024 年 4 月 24 日披露了微信的專有網路加密協議 MMTLS 與現代網路加密協議（如 TLS 或 QUIC+TLS）相比存在弱點。
- 2024 年 5 月 17 日——騰訊的回應：微信的安全協議核心是外層mmtls加密，目前確保外層mmtls加密是安全的。另一方面，內層的加密問題處理如下：核心資料流量已切換到AES-GCM加密，其他流量正在逐步從AES-CBC切換到AES-GCM。
原文點選標題。