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

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

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

有两个任务需要考虑：

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

这个问题中的三个协议：

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

现在我们分两种情况：

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

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

承诺TLS protocol：服务器经过身份验证（确实是 ubuntu.com）并且数据不会被任何中间人更改。

所以在做HTTPS时不需要在HTTP协议中添加校验和头。

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

2、文件提供者与客户端间接传输文件，通过CDN镜像、离线方式（U盘）。

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

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

Answer 2

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

带有摘要的示例响应。

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

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

您可以在 mozilla 网站上查看相关页面，以深入讨论 http 中的有效负载主体。

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

不，网络上的完整性由 TLS 确保。不应信任非 TLS 通信。见rfc8446