（转）Rustls 完成第三方安全审计

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 协议》，转载必须注明作者和本文链接