http - HTTP 响应 header 中的校验和 - 为什么不呢？

Question

当我开始从 HTTP 服务器下载文件时，我想知道某种文件校验和(如 SHA-256 哈希或其他任何东西)。它可以作为 HTTP 响应 header 之一进行传输。

HTTP etag 类似，但它仅用于使浏览器缓存无效，据我所知，每个站点都以不同的方式计算它，它看起来不像任何哈希我知道。

一些软件下载站点提供各种文件校验和作为单独的文件下载(例如，最新的 Ubuntu 16.04 SHA1 哈希:http://releases.ubuntu.com/16.04/SHA1SUMS)。将它们包含在 HTTP 响应 header 中并强制浏览器在下载结束时对其进行计算(并且不强制用户手动执行)会不会更容易。

我想整个基于 HTTP 的互联网都可以正常工作，因为我们使用的是 TCP 协议(protocol)，它是可靠的并确保接收到的字节与服务器发送的字节完全相同。但是，如果 TCP 如此“酷”，为什么我们要手动检查文件哈希值(参见上面的 Ubuntu 示例)？在文件下载过程中很多事情都可能出错(客户端/服务器磁盘损坏、服务器端文件修改等)。如果我是对的，一切都可以通过在下载开始时传递文件哈希来简单地解决。

Answer 1

在执行非 TLS 或间接 传输时，与文件分开提供的校验和用于完整性检查。

也许我知道您的疑问，因为我对校验和也有同样的疑问，让我们找出答案。

有两个任务需要考虑:

1. 文件在传输过程中损坏
2. 文件被黑客更改

本题中的三个协议(protocol):

1. HTTP协议(protocol)
2. SSL/TLS 协议(protocol)
3. TCP协议(protocol)

现在我们分为两种情况:

1。文件提供者与客户端直接传输文件，无需代理，无需离线(U盘)。

TCP 协议(protocol) promise :来自服务器的数据与客户端收到的数据完全相同，通过校验和确认。

TLS 协议(protocol) promise :服务器经过身份验证(真正的 ubuntu.com)并且数据不会被任何中间人更改。

所以在做HTTPS的时候就不需要在HTTP协议(protocol)中加入checksum header了。

但是当 TLS 未启用时，伪造可能会发生:中间的坏人给客户端一个坏文件。

2。文件提供者和客户端通过CDN、镜像、离线方式(U盘)间接传输文件。

像 ubuntu.com 这样的许多站点使用 3 方 CDN 来提供静态文件，CDN 服务器不由 ubuntu.com 管理。http://releases.ubuntu.com/somefile.iso 重定向到 http://59.80.44.45/somefile.iso。

现在必须在带外提供校验和，因为它未经过身份验证我们不信任该连接。所以HTTP协议(protocol)中的checksum header在这种情况下是束手无策的。