HTTP响应头中为什么没有校验和？

Question

在从HTTP服务器下载文件时，我希望能够获得某种类型的文件校验和（例如SHA-256哈希或其他任何东西），它可以作为HTTP响应头之一传输。

HTTP的etag也有类似的功能，但仅用于使浏览器缓存失效。从我注意到的情况来看，每个站点都是以不同的方式计算它，而且它看起来不像我知道的任何哈希。

某些软件下载站提供各种文件校验和作为单独的文件进行下载（例如最新的Ubuntu 16.04 SHA1哈希：http://releases.ubuntu.com/16.04/SHA1SUMS）。将它们包含在HTTP响应头中并强制浏览器在下载结束时计算它们（而不强迫用户手动计算）是否更容易？

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

- Greg Witczak

---

一个内容寻址系统会在下载文件之前检索每个文件的哈希值，以防止不必要地下载已经缓存的文件。 - Anderson Green

Answer 1

Digest 是用于传递所选资源（即负载体）的校验和的标准头。

以下是带有 digest 的示例响应。

>200 OK
>...
>Digest: sha-256=X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=
>
>{"hello": "world"}

Digest可以用于请求和响应中。在处理数据之前，使用摘要验证数据是一种好的做法。

您可以访问Mozilla网站上的相关页面，深入了解http中的有效载荷内容。

我猜整个基于HTTP的互联网都能正常工作，因为我们正在使用TCP协议。

不，Web的完整性由TLS保证。不应信任非TLS通信。请参见rfc8446

- Roberto Polli

Answer 2

当进行非 TLS或间接传输时，从文件中单独提供的校验和用于完整性检查。

也许我知道你的疑问，因为我曾经有同样的问题关于校验和，我们一起来找出答案吧。

这里需要考虑两个任务：

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

以及三种协议：

1. HTTP 协议
2. SSL/TLS 协议
3. TCP 协议

现在我们将其分成两种情况：

1. 文件提供者和客户端直接传输文件，没有代理，没有离线（USB 磁盘）。

TCP 协议 保证：服务器的数据与客户端接收到的完全相同，通过校验和和 ack。

TLS 协议 保证：服务器已经得到了认证（确实是 ubuntu.com），并且数据没有被中间人更改。

因此，在进行 HTTPS 时，HTTP 协议中不需要添加校验和头。

但是，当未启用 TLS 时，可能会发生伪造事件：中间的坏人给客户端提供了一个错误的文件。

2. 文件提供者和客户端间接传输文件，通过 CDN，通过镜像，通过离线方式（USB 磁盘）。

许多网站（如 ubuntu.com）使用第三方 CDN 来提供静态文件，其中 CDN 服务器不由 ubuntu.com 管理。 http://releases.ubuntu.com/somefile.iso 重定向到 http://59.80.44.45/somefile.iso。

现在必须提供校验和以保持带外可用，因为它未经身份验证，我们不信任连接。所以，在这种情况下，HTTP 协议中的校验和头无法解决问题。

- tianzhipeng

Answer 3

Ubuntu.com及其它相似网站上的哈希值有两个用途：

• 验证文件的完整性（是的，理论上浏览器可以为您检查它）
• 验证文件的正确性，以避免篡改（例如，攻击者可能会截取您的下载请求并向您提供恶意文件。虽然您在浏览器端可能受到https的保护，但在数据静态存储方面则不一定如此，例如USB外部磁盘，您可能需要通过比较哈希值来验证其正确性）

- Riccardo Galli

---

问题是为什么校验和不与数据一起在同一个HTTP响应中传递。 - CodeCaster

问题中有关SHA1SUMS的部分暗示了我们可以删除那种文件，这使我开始谈论安全性。也许我应该只是写一条注释而已 :-/ - Riccardo Galli