Зачем вычислять контрольные суммы загруженных файлов?

Я часто вижу контрольную сумму, указанную рядом с файлом, доступным для скачивания. Цель этой практики ускользает от меня. Очевидно, что он обнаруживает испорченные файлы, но что может быть причиной этого повреждения, и возможно ли это вообще?

Конечно, файл не будет поврежден ошибками передачи, поскольку они обнаруживаются сетевым протоколом. И, конечно же, любой злоумышленник, который может изменить файл для злонамеренных целей, может также изменить данную контрольную сумму. Проверяем ли мы ошибки жесткого диска? Есть ли вероятность того, что это произойдет при записи, а не при чтении? Я что-то упустил?

Выявлять коррупцию не совсем правильно. Чтобы убедиться в целостности программного обеспечения было бы более правильное использование. Обычно программное обеспечение не распространяется с одного сервера. Одно и то же программное обеспечение может распространяться со многих серверов. Поэтому при загрузке определенного программного обеспечения в качестве источника загрузки выбирается ближайший к месту назначения сервер, чтобы увеличить скорость загрузки. Однако этим «неофициальным» (сторонним) серверам не всегда можно доверять. Они могут / могут включать трояны / вирусы / рекламное ПО / бэкдоры в программу, что не очень хорошо .

Таким образом, чтобы гарантировать, что загруженное программное обеспечение точно такое же, как и у «официального» программного обеспечения, выпущенного соответствующей организацией, используется контрольная сумма. Алгоритмы, используемые для генерации контрольных сумм, таковы, что даже небольшое изменение в программе приводит к совершенно другой контрольной сумме.

Пример взят из Практической Unix и Internet Security

MD5 (в синей рамке 1500 долларов) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (в синей рамке 1100 долларов) = d6dee11aae89661a45eb9d21e30d34cb

Сообщения, которые отличаются только одним символом (и внутри этого символа только одним двоичным битом), имеют совершенно разные дайджесты сообщений.

Если загруженный файл имеет ту же контрольную сумму, что и контрольная сумма, указанная на «официальном» веб-сайте, то можно предположить, что программное обеспечение не было изменено.

Примечание: теоретически два разных файла МОГУТ иметь одинаковое значение хеш-функции. Чтобы алгоритм хэш / контрольной суммы считался безопасным, в вычислительном отношении очень дорого находить другой файл, который выдает такую ​​же контрольную сумму.

И, конечно же, любой злоумышленник, который может изменить файл для злонамеренных целей, может также изменить данную контрольную сумму.

Не всегда.

Вы могли бы иметь ссылку на контент вместе с контрольной суммой, поданной на HTTPS. Ссылка может быть незашифрованной - обычным HTTP или FTP или чем-то еще.

С другой стороны, незашифрованное соединение может легко получить среднюю пропускную способность, с другой стороны, оно может быть более быстрым или более удобным для веб-мастера (требуется меньше вычислительных ресурсов и возможности сети для кэширования такого содержимого).

Если контрольная сумма передается по неразорванному доверенному соединению, а полезная нагрузка совпадает с контрольной суммой, вы получаете лучшее из обоих миров (при условии, что контрольная сумма является криптографически безопасной).

Тем не менее, вы напомнили мне, что есть дистрибутивы, которые утверждают, что они «безопасны», и все же их веб-сайт работает только по HTTP, как и ссылки на их изображения.

Примеры:

• http://www.networksecuritytoolkit.org/nst/index.html
• http://std.org/download.html

Это довольно забавно, потому что вы не можете быть более неуверенными в этом. Даже если они сами не являются злонамеренными, любой провайдер может легко заменить как веб-сайт, так и изображение на фальшивые, и заставить кого-то установить защищенную операционную систему, создавая впечатление, что они получают «безопасный» дистрибутив Linux, является идеальным решением. Pwnage.

Что касается того, почему проверка ошибок TCP / IP не улавливает все: с /programming//a/17083365/2551539

Могут возникнуть разные ошибки (которые обнаружит TCP) [указал Якоб Кралл] :

• Неправильный порядок пакетов
• Потеря пакетов
• Поврежденные данные внутри пакета
• Фантомные пакеты (получатель получает пакеты, которые никогда не отправлялись)

Изменить с некоторой дополнительной информацией:

Страница 9 этого исследования: http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf предполагает, что существуют ошибки, которые могут остаться незамеченными TCP. Насколько я понимаю, это происходит, когда ошибочная датаграмма (называемая в исследовании «плохим близнецом») имеет ту же контрольную сумму, что и предполагаемая дейтаграмма (называемая в исследовании «хорошим близнецом»).

Возможны ошибки при передаче. Протоколы канального уровня обычно содержат контрольные суммы или коды, исправляющие ошибки, чтобы избежать их, но они не идеальны: существует небольшая вероятность того, что ошибка останется без исправления.Пакеты TCP также содержат контрольную сумму, которая уменьшает вероятность ошибок на 2 ^ 16. Это делает очень малую, но ненулевую вероятность ошибки передачи. Это та вещь, с которой большинство людей никогда не столкнется по незнанию за всю свою жизнь, но это не тот диапазон криптографических контрольных сумм, который никогда не достигает миллиарда лет.

Аппаратная ошибка на клиенте, такая как повреждение диска, вряд ли будет обнаружена путем проверки сразу после загрузки, поскольку контрольная сумма будет рассчитываться из кэшированной копии. С другой стороны, полезно проверить загрузочный носитель на наличие повреждений, если он не загрузился - вы действительно тестируете носитель и имеете предположение, что оборудование может быть неисправным.

Реальная причина для вычисления контрольных сумм заключается в обнаружении ошибок на уровне программного обеспечения. Это случается. Возможные ошибки включают в себя:

• Файл был частично загружен. Веб-серверы и браузеры, как правило, плохо распознают прерванные соединения и очищают неполные файлы. Ошибка может быть при загрузке или при загрузке, это добавляет.
• По пути была некоторая коррупция. Например, некоторый промежуточный узел в распределении файла решил применить преобразование кодировки текста к двоичному файлу. Или какой-то неправильно настроенный сервер выдает сообщение об ошибке вместо содержимого.
• Вариант: был загружен неправильный файл.
• Редко, но может быть полезно для защиты от: злоумышленник изменил файл, но не смог изменить контрольную контрольную сумму. Инфраструктуры безопасности, как правило, затрудняют злоумышленнику распространение неверной контрольной суммы, чем неверный файл. Например, большие файлы часто распространяются через зеркала, тогда как контрольные суммы обслуживаются центральным сайтом с меньшими возможностями для подделки (доступ к серверу только руководителям проектов, распространение через HTTPS).

На практике при проверке размера загружаемого файла выявляются наиболее распространенные ошибки: усеченные или недопустимо преобразованные файлы. Преимущество контрольных сумм состоит в том, что они обнаруживают строго больше проблем.

Теоретически, сеть будет доставлять каждый отдельный сегмент должным образом, и они будут правильно собраны на диске, и все будет в порядке.

На самом деле компьютеры - это машины и программное обеспечение, которые спроектированы и созданы ошибочными людьми. В случае, если загрузка по каким-либо причинам не удалась, например, загрузка осуществляется через какое-то промежуточное устройство, будь то безобидное или вредоносное, которое портит данные, неплохо иметь способ проверить, что файл почти наверняка был загружается как точная копия файла на стороне провайдера.

Высококачественная контрольная сумма - это надежный метод проверки целостности данных.

Никакая контрольная сумма не может быть надежной на 100%, потому что многие файлы отображаются на одну и ту же контрольную сумму.

Когда мы добавляем еще одну контрольную сумму в поезд, мы умножаем вероятность обнаружения ошибки.

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

Контрольная сумма также поможет предотвратить повреждение загрузки из-за следующей ситуации:

Во время обслуживания загрузки на сервере произошла внутренняя ошибка, поэтому загрузка прекращается.

Когда это происходит, есть несколько возможных результатов:

• Хороший сервер - реализация сервера из кодировки передачи блочной является не глючит:
  • Хороший клиент (например, cURL, wget) сможет сообщить вам, что это плохая загрузка, так как завершающий блок никогда не отправлялся с сервера.
  • Плохой клиент будет считать загрузку завершенной, поскольку с сервера больше не поступает никаких данных.
• Плохой сервер - реализация сервера из кодировки передачи блочной является ошибку, так как отправляет завершающий кусок для этой неудачной загрузки:
  • Любой клиент будет думать, что эта загрузка успешно завершена.

Я видел такое поведение среди популярных клиентских инструментов и серверных сред, поэтому, если вы не используете контрольную сумму, то в случае «хороший сервер + плохой клиент» или «плохой сервер + любой клиент» ваша поврежденная загрузка будет незамечена ,