考虑一下。许多提供软件下载的网站也提供 MD5 或 SHA1 哈希值,供用户验证下载文件的完整性。然而,这些网站中很少有真正在网站本身上使用 HTTPS 加密或数字签名。
因此,如果您从实际上是未经身份验证的来源下载文件,并使用来自同一来源(甚至另一个未经身份验证的来源)的哈希验证它,那么散列文件的真正价值是什么?这是否不会建立一种错误的安全感,因为(在没有数字签名的情况下)下载和哈希都可能在用户不知情的情况下被篡改?
考虑一下。许多提供软件下载的网站也提供 MD5 或 SHA1 哈希值,供用户验证下载文件的完整性。然而,这些网站中很少有真正在网站本身上使用 HTTPS 加密或数字签名。
因此,如果您从实际上是未经身份验证的来源下载文件,并使用来自同一来源(甚至另一个未经身份验证的来源)的哈希验证它,那么散列文件的真正价值是什么?这是否不会建立一种错误的安全感,因为(在没有数字签名的情况下)下载和哈希都可能在用户不知情的情况下被篡改?
因此,如果您从实际上是未经身份验证的来源下载文件,并使用来自同一来源(甚至另一个未经身份验证的来源)的哈希验证它,那么散列文件的真正价值是什么?
提供的哈希值让您可以再次检查您下载的文件是否在传输过程中意外损坏,或者您从其他来源(更快的镜像)下载的文件是否与本网站上可供下载的文件相同。
但是,实际上并没有太多额外的安全性。足够熟练的破解者可以将文件替换为恶意修改的版本,并将哈希替换为与修改后的文件匹配的版本;或者他可以通过网络 MITM 请求,并用他自己的文件替换请求的文件和他自己的哈希值。
那里的好处确实是有限的。正如您所指出的,如果您可以替换站点上的一个东西,您可能可以同时替换两个。
但是,这确实有一些好处:
虽然通过使用公钥/私钥对签署文件可以获得额外的安全性,但对于大多数应用程序来说,使用密钥的实际好处并不比没有密钥更大。如果我在网站上发布我的密钥并签署所有内容而不是发布哈希,攻击者可以通过替换密钥来实现与替换哈希相同的效果。真正具有独立分发的大型项目需要这个额外的层(想到 Debian),但我认为很少有人会从中受益。
要使散列具有某些与安全相关的值,必须同时满足以下两个条件:
因为,如果文件也使用 HTTPS 提供,那么散列往往毫无意义:SSL 已经确保了传输过程中的完整性。
散列不会保护控制服务器的攻击者,因为他可以修改散列,就像他可以修改文件一样。
已发布哈希的有用性的一个示例是,当您在某个日期下载文件,然后想稍后检查您拥有的副本是否正确,因为您不一定信任本地存储的完整性(例如,它是USB 密钥上可能已被不怀好意的人暂时盗用)。另一个例子是当下载本身来自 p2p 网络时,因为这样的事情对于将批量软件分发给大量客户端非常有效(这就是暴雪下载器所做的):使用 p2p 获取文件,然后获取小哈希值来自主 HTTPS 站点。第三个例子(我专业遇到的)是在繁重的审计条件下(例如创建新的根 CA)构建可信系统时:您希望审计员能够验证所使用的软件是真实的。如果散列文件是分发的(通过 HTTPS),那么审核员只需根据本地存档检查它;否则,审核员必须见证整个下载过程。考虑到审计员的小时费率,散列是可取的。
您是对的,仅拥有原始哈希的好处有限,因为您还需要安全地分发哈希,并且大多数人不知道如何正确检查它或解决许多可能的问题。
获得良好安全性的正确方法是使用公钥技术对哈希进行签名,并将其无缝集成到整个软件分发方案中。仍然需要安全地分发公钥,但这可以一次性完成,例如在安装操作系统时。我认为这基本上是使用 Windows 和 MacOS 进行操作系统更新和一些主要软件包(如 Office)所做的。
最重要的是,您需要的几乎所有软件都包含在相同的标准密钥中。这基本上是大多数开源软件发行版所发生的事情,例如 Debian、Ubuntu、Red Hat、Suse 等。它们安全地分发了数以万计的软件包,所有软件包都使用作为发行版一部分管理的密钥自动签名,因此高度安全。它主要发生在没有任何人需要进行任何手动检查的情况下。