什么是最佳SRI哈希大小

Question

我最近发现了以下漂亮的小站点，用于为外部加载的资源生成SubResource Integrity（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文档，我发现

完整性值可能包含多个由空格分隔的哈希。如果资源与那些哈希值之一匹配，将被加载。

但是，该匹配如何执行？在一个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，“用户代理将在列表中选择最强的哈希函数”。

2. 真的有人会期望一个哈希能够匹配而不是三个都匹配吗？

不会。但是就浏览器的行为而言：如果最强的哈希匹配，则浏览器将使用该哈希，而忽略其余的哈希（因此其他哈希是否匹配也无所谓）。

3. 提供所有三个哈希值而不是仅提供一个哈希值有什么好处吗？

据我所知，目前在实践中没有任何好处。这是因为根据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值。是因为它在中间，不是太大，不是太小？

Dunno为什么他们选择那样做。但是，由于要求浏览器支持SHA-512哈希，因此您不能通过指定SHA-384哈希来获得任何收益-实际上，您只是失去了拥有最强大的哈希函数的价值。

5. 出于好奇，可以integrity在<script>和旁边的任何标签上使用该属性<link>。

不，还不能-尚未。

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

SRI的计划一直是最终将其用于那些人。如https://w3c.github.io/webappsec-subresource-integrity/#verification-of-html-document-subresources中所述：

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

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