2

我使用srihash.org为 URL https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js生成了以下代码：

<script src="https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js"
integrity="sha384-CAN0Iz/H09oATWPeJZclEOAM/nF1cq3DSuAbxi9IMbZIx8m3ERInrpuk11n+lHRq"
crossorigin="anonymous"></script>

在尝试加载包含完整性检查脚本的页面时，我在 Windows 上的 Chrome 50 中收到以下错误：

无法在资源“ https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js ”的“完整性”属性中找到有效的摘要，计算出的 SHA-256 完整性为“vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=”。该资源已被阻止。

我还尝试手动生成哈希（同样，在 Windows 上，openssl-1.0.2h），使用：

openssl dgst -sha384 -binary Cesium.js | openssl base64 -A

导致：

X5EHALkqk8r9hyCKwav7y+6BOUg2dRH90/qSxdytan2SQQB9g8jsYYWLDKzNeKx4

当使用 Chrome 加载 Cesium.js 时，此哈希有效。然而，这提出了两个哈希中哪一个是正确的问题......排除了 MITM 攻击的可能性，我认为它与行尾或编码有关。Cesium.js似乎有 Windows 行结尾，在 Chrome 中加载它的 HTTP 响应附在下面。

如何解释这两种哈希之间的区别，哪一种是正确的？

Cesium.js 的 HTTP 响应标头：

HTTP/1.1 200 OK
Cache-Control: max-age=172800
Content-Length: 494091
Content-Type: application/javascript
Content-Encoding: gzip
Last-Modified: Mon, 02 May 2016 15:12:32 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/8.5
x-amz-id-2: giU2DeYQi87OAkuyr2qKeZx8KRihIY7TV9qcJShi/YVl+C5K50mHeSLFWYhA8k5Oc+A50Oxjh/4=
x-amz-request-id: 112881D9D52248F6
X-Powered-By: ARR/3.0
X-UA-Compatible: IE=edge
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers: Content-Type,X-Requested-With
Date: Mon, 30 May 2016 12:49:46 GMT
4

2 回答 2

1

经过一番挖掘，我发现 srihash.org 生成的哈希是不正确的。

不正确的结果是由于两个因素的组合：

于 2016-06-08T10:52:40.907 回答
0

正如您所怀疑的，这显然是与编码相关的 chrome 错误。其他人报告其他脚本的问题。

查看这个关于 chrome 和 openssl 之间不一致的错误页面。

作为临时解决方法，我会添加

vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=

到您信任的 SHA256 完整性属性（在验证下载的脚本实际上是正确的之后）。

Chrome 可能在解压缩之前使用特殊编码计算此哈希值。

于 2016-06-07T12:18:13.993 回答