假设链接下载的页面和下载本身都在 HTTPS 上的受信任域上，是否有理由担心检查下载文件的哈希值/校验和（特别是可执行文件/安装程序，它们本身也没有由操作系统信任的东西签名）？
据我了解，这样做的原因是为了捕获下载错误（尽管 TCP 应该这样做？）或感染文件的恶意攻击。
但是 HTTPS（TLS）应该已经提供了全面的保护，那么手动验证是否还有其他价值呢？
答案1
我认为 HTTPS 不会捕获其中任何一个。据我所知，HTTPS 不会提供针对 TCP 损坏的额外保护。
我不是安全专家，但我知道 TLS（HTTPS）可以做这两项事情：
- 验证您连接的服务器是否确实是他们声称的那个服务器。
例如，如果您输入https://microsoft.com你的流量将被发送到https://badguys.com而是在你不知情的情况下（DNS 欺骗)，您将收到证书错误。当然，坏人可以在https://badguys.com那索赔成为https://microsoft.com但它不会由有效的证书颁发机构。 - 对流量进行加密，使其无法被读取或更改中间人攻击 (MITM)。在这种情况下，有人可以看到您的所有网络流量。如果您没有使用 TLS，他们可以检测到请求
GET并开始向您发送虚假数据，以代替来自 Web 服务器的真实数据。
回到下载的话题，许多网站将他们的大容量下载分发到镜像中。如果镜子被盗用后，文件可能会被恶意版本替换。即使镜像使用 TLS，如果它被黑客入侵或被错误地添加到镜像列表中，您也可能从 HTTPS 站点下载恶意版本。当然，如果发生这种情况，他们会更新镜像上的校验和。
这就是为什么你永远不应该用镜像的校验和来验证下载，而应该只使用原始站点的校验和（按照这个问题）。
答案2
补充 Ian 的回应。
在 MITM 攻击中，中间人无法将有效载荷更改为恶意内容，因此校验和毫无用处。
如果 MITM 在客户端的机器上安装了根证书，或者能够以某种方式操纵连接，那么校验和也是无用的，因为他可以更改显示的校验和。
对于服务器攻击，同样的事情也应该发生，如果他已经可以访问服务器，他将能够更改校验和。但是，如果服务器是分开的（下载服务器和显示下载链接/校验和的服务器），那么最好提供校验和。
所以我认为经验法则是：如果显示校验和的服务器与提供下载文件的服务器相同，则校验和无用。如果您有多个镜像，则必须这样做。
较晚更新/与安全不完全相关但很有用：
我发现添加校验和的另一个有效理由，即对于可能被存档的文件（例如，在archive.org中），以便用户知道他们获得的文件与在您的网站上可用时的文件相同。
而且，如果您尝试在互联网上查找文件的特定版本（考虑到它是在相同的可执行文件名称下版本），它也会有所帮助，一些镜像站点或存档站点为搜索引擎提供了文件的 MD5/SHA1，因此您可能能够通过搜索哈希值更容易地找到它（我过去实际上遇到过这个特定问题，并通过搜索 HASH 找到了它）。