2016-05-30 2 views
2

Я создал следующий код, используя srihash.org для URL https://cesiumjs.org/releases/1.21/Build/Cesium/Cesium.js:srihash.org не работает .js файл из cesiumjs.org

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

При попытке загрузить страницу, которая содержит сценарий целостности проверил, я получить следующее сообщение об ошибке в Chrome 50 на Windows:

Не удалось найти правильный дайджеста в «целостности» атрибут для ресурса «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 

Этот хэш работает, когда загрузка Cesium.js с помощью Chrome. Тем не менее, возникает вопрос, какой из двух хэшей правильный ... Оставив маловероятную возможность атаки MITM, я предполагаю, что это имеет какое-то отношение к концам строк или кодированию. Cesium.js, похоже, имеет окончание строки Windows, а HTTP-ответ загрузки его в Chrome приведен ниже.

Как можно объяснить разницу между двумя хэшами, и какой из них правильный?


заголовки ответа HTTP для 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 

ответ

1

После некоторого рытья я узнал, что хэш, созданный srihash.org, неверен.

Некорректный результат обусловлен сочетанием двух факторов:

  • Cesium.js из cesiumjs.org всегда подается с Content-Encoding: gzip, даже если запрос не содержит Accept-Encoding: gzip.

  • srihash.org (см. source) использует xhr2 для извлечения ресурсов, которые does not support gzip encoding.

0

Как вы подозревали, что это, видимо, хром ошибка, связанная с кодировкой. Другие люди сообщают об этой проблеме для других сценариев.

Оформить заявку this bug page о несоответствиях между хром и openssl.

В качестве временного решения, я хотел бы добавить

vGCl/67DuYY5UzwNQGGpYh2gztA4PhvD + I4pcX7TWcU =

в доверенном целостности SHA256 атрибутов (после того, как проверить загруженный скрипт на самом деле право один) ,

Хром, вероятно, вычисляет этот хэш перед распаковкой со специальной кодировкой.

+0

Нет, это не проблема. Как я уже сказал в своем вопросе, SHA-384, который я создал вручную, фактически работает. Тот факт, что Chrome ссылается на хэш SHA-256 в сообщении об ошибке, не означает, что он не поддерживает SHA-384. – ValarDohaeris

+0

На самом деле я повторяю. Я отредактирую свой ответ позже. Извините –

+0

Интересно, но на самом деле я использую более новую версию Chrome, на которую не влияет эта ошибка. Кроме того, как я уже сказал, поведение Chrome и OpenSSL в моем случае было последовательным. – ValarDohaeris

Смежные вопросы