2

I have generated the following code using srihash.org for 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>

When trying to load the page that contains the integrity-checked script, I get the following error in Chrome 50 on Windows:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js' with computed SHA-256 integrity 'vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU='. The resource has been blocked.

I also tried to generate the hash manually (again, on Windows, openssl-1.0.2h), using:

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

resulting in:

X5EHALkqk8r9hyCKwav7y+6BOUg2dRH90/qSxdytan2SQQB9g8jsYYWLDKzNeKx4

This hash works when loading Cesium.js with Chrome. However, this raises the question which of the two hashes is correct... Leaving out the unlikely possibility of a MITM-attack, I assume it has something to do with line endings or encoding. Cesium.js seems to have Windows line endings, and the HTTP response of loading it in Chrome is attached below.

How can the difference between the two hashes be explained, and which one is correct?

HTTP response headers for Cesium.js:

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
ValarDohaeris
  • 6,064
  • 5
  • 31
  • 43

2 Answers2

2

After some digging, I found out that the hash generated by srihash.org is incorrect.

The incorrect result is due to the combination of two factors:

ValarDohaeris
  • 6,064
  • 5
  • 31
  • 43
0

As you suspected, this is apparently a chrome bug related to encoding. Other people report the issue for other scripts.

Check out this bug page on inconsistencies between chrome and openssl.

As a temporary workaround, I'd add

vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD+I4pcX7TWcU=

to your trusted SHA256 integrity attributes (after having verified the downloaded script is actually the right one).

Chrome is probably computing this hash before the unzip, of with a special encoding.

Regis Portalez
  • 4,675
  • 1
  • 29
  • 41
  • No, this is not the problem. As I stated in my question, the SHA-384 that I generated manually actually works. The fact that Chrome cites the SHA-256 hash in the error message doesn't mean that it doesn't support SHA-384. – ValarDohaeris Jun 07 '16 at 12:46
  • Interesting, but I'm actually using a more recent version of Chrome which is not affected by this bug. Also, as I stated, the behavior of Chrome and OpenSSL was consistent in my case. – ValarDohaeris Jun 08 '16 at 10:55