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
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:
Cesium.js from cesiumjs.org is always served with Content-Encoding: gzip, even if the request does not contain Accept-Encoding: gzip.
srihash.org (see source) uses xhr2 to fetch resources, which does not support gzip encoding.