（轉）Rustls 完成第三方安全審計

AllenXu9527發表於2020-07-01
RustTLS

Rustls是一個用Rust編寫的現代TLS庫，它使用ring forcryptography和libwebpki進行證照驗證。

該專案由CNCF發起和贊助，由Cure53團隊的四名專業成員花費30天來完成審計（2020年5月下旬和2020年6月上旬）。因為CNCF有一些專案依賴於rustls，比如 linkerd。本次審計也包括了rustls的依賴庫：rustls-native-certs，sct.rs，ring和webpki。

（注： Cure53是德國知名網路安全公司，去年還分析過「學習強國App」，發現其中存在的後門 。。 ）

Cure53 團隊建立了一個專用的Slack Channel來溝通交流。 審計範圍內每個專案的維護代表均被邀請參與討論，並提供反饋，範圍澄清，問題答案等等。

審計結果： 只有四個小發現，均不是漏洞（vulnerabilities），只是一些缺陷（weaknesses）。

Cure53團隊審計過程學習：

  1. 使用 Clippy 掃描程式碼庫中的問題
  2. 跟蹤了專案中每一個單元測試。 Rustls利用libfuzzer-sys（LLVM的libfuzzer的Wrapper）以及客戶端和伺服器訊息的語料庫作為樣本輸入，因此給定的測試用例已經涵蓋了警報和握手訊息的大量示例輸入，所以Cure53不再關注模糊測試（Fuzz）
  3. Cure53團隊還在邏輯方面研究了程式碼的正確性：TLS狀態機實現是否正確、整數算術釋放正確處理可能截斷的問題、協議解析（QUIC是否滿足IETF規範）和實現程式碼的正確性等。
  4. 特別關注檢查可能包含嚴重邏輯問題的程式碼，比如webpki中的主機名驗證程式碼。
  5. 對ring的核心功能進行了審計：
  • 驗證了基於分組密碼的AEAD（例如AES-GCM）的正確實現
  • 檢查ChaCha20繫結的功能正確性
  • 檢查了Curve25519的基本橢圓曲線演算法的功能正確性, 還驗證了在其上實現的原語，例如Diffie-Hellman的X25519和數字簽名的Ed25519，以確保功能正確性
  • 檢查了由環形庫暴露的每個恆定時間比較功能的功能正確性
  • 檢查Poly1305的繫結是否正確使用
  • 檢查了HKDF實現的功能正確性
  • 特別注意支援的RSA PKCS標準和提供的填充方法
  • 對於ECDSA，稽核員已驗證了針對有偏的隨機數生成的最近攻擊（例如LadderLeak）的不適用性
  • 特別注意的是，要確定所提供的AES實現是否具有s-box或類似構造的旁通道特性

缺陷：

  • 使用 unchecked unwrap 。程式碼中並不總是正確處理Option的值，使用了類似於 is_some之類的方法，雖然這些程式碼是安全的，但其實可以用 if let之類進行更嚴謹的處理。
  • 在審查webpki 時，發現名稱約束程式碼允許使用非連續子網掩碼。 這意味著像42.42.42.42這樣的子網掩碼將被驗證者視為有效，這可能會帶來意想不到的後果。建議將名稱約束中包含不連續子網掩碼的證照視為無效。
  • 在檢視DER解析和生成程式碼時，發現rustls / src / x509.rs檔案中的wrap_in_asn1_len函式在長度大於0xffff位元組的輸入序列上無法正常執行。

審計總結：

  1. Cure53無法發現任何破壞rustls的安全漏洞。
  2. 稽核團隊成員認為總體程式碼質量是出色的，這得益於 Rust 語言。
  3. 所檢查的程式碼始終具有良好的文件編制和可讀性，表明rustls複雜區的開發和文件編制過程中已根深蒂固地使用了安全流程。 從設計的角度以及從實施的角度來看，整個範圍都可以被認為是極高的標準。
  4. 從密碼學角度來看，密碼操作的執行和管理都非常謹慎。可以說，就密碼工程而言，rustls 在協議層和基礎層中表現出的謹慎程度和質量是卓越的。
  5. 關於rustls或其底層ring 庫，未發現任何問題。看得出來 rustls 的開發團隊對於如何正確實現TLS，以及避免TLS生態中常見陷阱有著豐富的經驗，並且在開發過程中非常注重安全性的開發方法

相關連結：

rustls： github.com/ctz/rustls
原文： jbp.io/2020/06/14/rustls-audit.html
完整報告： github.com/ctz/rustls/blob/master/...

本作品採用《CC 協議》，轉載必須註明作者和本文連結

相關文章