HTTP响应标头中的校验和 - 为什么不呢？

Question

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

Http etag是类似的，但它仅用于使浏览器缓存无效，而且从我注意到，每个网站都以不同的方式计算它，它看起来不像我知道的任何哈希。

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

我猜整个基于HTTP的互联网正在运行，因为我们正在使用TCP协议，这是可靠的，并确保接收的字节与服务器发送的字节完全相同。但是如果TCP是如此“酷”，我们为什么要手动检查文件哈希（请参阅Ubuntu示例）？在文件下载期间（客户端/服务器磁盘损坏，服务器端的文件修改等），很多事情都可能出错。如果我是对的，只需在下载开始时传递文件哈希就能解决所有问题......

Answer 1

Digest是用于传送资源（即有效负载主体）的所选表示形式的校验和的标准标头。

带有摘要的示例响应。

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

Digest可以在请求和响应中使用。 在处理摘要之前，最好先对摘要进行验证。

您可以在related page on mozilla website上找到有关http中有效内容正文的深入讨论。

  

我想整个基于HTTP的Internet都可以正常工作，因为我们使用的是TCP协议

否，TLS可以确保Web的完整性。非TLS通信不应 被信任。参见rfc8446

Answer 2

与文件分开提供的校验和在进行Non TLS或indirect传输时用于完整性检查。

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

要考虑两个任务：

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

此问题中的三个协议：

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

现在我们分为两种情况：

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

TCP protocol的承诺：通过校验和和确认，来自服务器的数据与客户端接收的数据完全相同。

TLS protocol承诺：服务器已通过身份验证（实际上是ubuntu.com），并且任何中间人都不会更改数据。

因此，在执行HTTPS时无需在HTTP协议中添加校验和标头。

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

2。文件提供者和客户端通过CDN，通过镜像，通过脱机方式（usb磁盘）间接传输文件。

许多站点，例如ubuntu.com，都使用3方CDN来提供静态文件，而CDN服务器不受ubuntu.com管理。 http://releases.ubuntu.com/somefile.iso重定向到http://59.80.44.45/somefile.iso。

现在必须以带外方式提供校验和，因为该校验和未经身份验证，我们不信任该连接。因此，在这种情况下，HTTP协议中的校验和标头是无能为力的。

Answer 3

ubuntu.com和类似网站上的哈希有两个目的：

• 检查文件的完整性（是的，假设浏览器可以为您检查）
• 检查文件的正确性，以避免篡改（例如，攻击者可以拦截您的下载请求并为您提供恶意文件。虽然您可能会被https浏览器方面覆盖，但对于静态数据而言则不然，例如一个usb外部磁盘，你可能想通过比较哈希来检查它的正确性）