最佳 SRI 哈希大小是多少？

Question

我最近发现了以下 nifty little site 用于为外部加载的资源生成子资源完整性 (SRI) 标签。例如输入最新的jQuery URL（https://code.jquery.com/jquery-3.3.1.min.js），得到如下<script>标签：

<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8= sha384-tsQFqpEReu7ZLhBV2VZlAu7zcOV+rXbYlF2cqB8txI/8aZajjp4Bqd+V6D5IgvKT sha512-+NqPlbbtM1QqiK8ZAo4Yrj2c4lNQoGv8P79DPtKzj++l5jnN39rHA/xsqn8zE9l0uSoxaCdrOgFs6yjyfbBxSg==" crossorigin="anonymous"></script>

我了解 SRI 哈希的用途，并且我知道它们可以使用不同的哈希大小（256 位、384 位或 512 位），但我以前从未见过像这样同时使用这三个哈希值。挖掘MDN docs，我发现

一个完整性值可能包含多个由空格分隔的哈希值。如果资源与其中一个哈希值匹配，则将加载该资源。

但是这种匹配究竟是如何进行的呢？是时候在一篇 SO 帖子中提出多个问题了...

1. 浏览器是先尝试匹配最长的哈希，因为它更安全，还是先匹配最短的哈希，因为它更快？
2. 真的会期望 一个 哈希匹配而不是所有三个（除了开发人员错误输入哈希的小例子）？
3. 提供所有三个哈希而不是只提供一个有什么好处？
4. 类似于#1，如果你只提供一个哈希值，你应该使用哪个？我通常会看到网站（例如，Bootstrap）在其示例代码中提供 sha384 值。是因为它在中间，不大也不小？
5. 出于好奇，integrity 属性能否用于除<script> 和<link> 之外的任何标签。我特别想知道<img>、<source> 等多媒体标签。

Answer 1

1. 浏览器是先尝试匹配最长的哈希值，因为它更安全，还是先匹配最短的哈希值，因为它更快？

根据https://w3c.github.io/webappsec-subresource-integrity/#agility，“用户代理将选择列表中最强的哈希函数”。

1. 真的会期望 一个 哈希匹配而不是全部三个吗？

没有。但就浏览器行为而言：如果最强的哈希匹配，浏览器会使用它并忽略其余的（所以无论如何其他是否匹配都无关紧要）。

1. 提供所有三个哈希而不是只提供一个有什么好处？

据我所知，实践中没有当前的好处。这是因为根据 https://w3c.github.io/webappsec-subresource-integrity/#hash-functions，“符合标准的用户代理必须支持 SHA-256、SHA-384 和 SHA-512 加密哈希函数”。

所以目前，如果你只指定一个 SHA-512 哈希值，所有支持 SRI 的浏览器都会使用它。

但根据https://w3c.github.io/webappsec-subresource-integrity/#agility，指定多个哈希的意图是“在面对未来的密码学发现时提供敏捷性……鼓励作者在可用时开始迁移到更强大的哈希函数”。

换句话说，在未来的某个时候，浏览器将开始添加对更强大的哈希函数的支持（基于 SHA-3 的 https://en.wikipedia.org/wiki/SHA-3 或其他）。

因此，由于您需要继续针对较旧的浏览器以及较新的浏览器，因此在一段时间内您将针对某些 SHA-512 是最强哈希函数的浏览器同时针对届时出现的新浏览器将增加对某些 SHA-3（或其他）哈希函数的支持。

因此，在这种情况下，您需要在 integrity 值中指定多个哈希值。

4. 与 #1 类似，如果您只提供一个哈希值，您应该使用哪个？

一个 SHA-512 值。

我通常会看到网站（例如 Bootstrap）在其示例代码中提供 sha384 值。是因为它在中间，不大也不小？

我不知道他们为什么选择这样做。但由于浏览器需要支持 SHA-512 哈希，因此指定 SHA-384 哈希并不会带来任何好处——事实上，您只会失去拥有最强哈希函数的价值。

5. 出于好奇，integrity 属性能否用于除<script> 和<link> 之外的任何标签。

不，不可能——还没有。

我特别想知道<img>、<source> 等多媒体标签。

正如https://w3c.github.io/webappsec-subresource-integrity/#verification-of-html-document-subresources 解释的那样，该计划一直是让 SRI 最终也用于这些 —

注意：本规范的未来版本可能包括对所有可能的子资源的完整性支持，即a、audio、embed、iframe、img、link、@987654339 @、script、source、track 和 video 元素。

……但我们还没有进入那个未来。