Rustls的第三方审计

在2020年5月和6月，Cure53完成了对ring、webpki和rustls的审计。他们的报告(PDF)全面描述了审计情况，读起来很有趣。

不过，首先，(奎恩项目的)Dirkjan Ochtman最终实现了这一目标，值得非常感谢。我们在2018年巴黎RustFest上首次讨论了进行这样的审计的可能性。为了获得赞助商，他花了将近两年的时间坚定不移地工作。谢谢德尔坎！

云本地计算基金会(Linux基金会的一部分)应在链接器数据平面中使用沙沙的浮标公司的要求资助了这次审计。因此，进一步感谢Linux基金会的Chris Aniszczyk和浮标公司的Oliver Gould对这些项目的支持。(注：原生云计算基金会是Linux基金会的一部分)应浮标基金会的要求资助这次审计，浮标基金会的Chris Aniszczyk和浮标基金会的奥利弗·古尔德对这些项目给予了支持。

“[..]。审计团队认为总体代码质量非常好，可以证明所有范围的项目都一致地留下了坚实的印象。“。

“无论是从设计的角度还是从实现的角度来看，整个范围都可以被认为是异常高标准的。”

开发商提供高质量TLS实施的意图非常明确，这一目标可以被认为是成功实现的。“。

“这里和那里的小建议对任何项目来说都是可能的，但这并不能改变这样一个事实，即在沙沙中真的没有太多需要改进的地方。Cure53非常高兴能对展示的软件留下令人难以置信的印象。

有两个信息性的发现和两个轻微的严重程度的发现。详细内容见报告，下面的讨论反映了我对这些问题的看法。

这一发现表明RING使用来自EverCrypt项目的正式验证的密码学实现，很难反对基础密码学代码的形式验证。这里值得注意的是，RING确实已经使用了正式验证的curve25519实现(来自Fiat-Crypto项目)。

这一发现与unwork()的实例相关，这些实例没有出现恐慌，但是很难推断是这样的情况。推理跨越了几个不同的模块，这本身就是一个可读性和维护风险。因此，正在讨论的代码已经得到了改进。

此发现涉及表示为RFC5280中指定的IP地址空间的证书名称约束。RFC没有指定对网络掩码的任何限制，但是不允许稀疏掩码似乎是明智的。

这一发现正确地指出了Rustls中的一个函数，该函数在应用于大于64KB的X.501名称时产生不正确的输出。虽然这是一种非常不可能的情况，并且错误不会导致不安全的操作(但可能是连接故障)，但该函数已经更正，可以为所有输入生成有效的输出。

与其他形式的软件测试一样，归根结底，第三方审核只能显示缺陷的存在，而不能显示缺陷的缺失。话虽如此，报告中的积极反馈和这些发现的低严重性肯定是令人鼓舞的。