Чому обчислюють контрольні суми завантажених файлів?

Я часто бачу контрольну суму, яку подають поруч із файлом, доступним для завантаження. Мета цієї практики ухиляється від мене. Це, очевидно, для виявлення пошкоджених файлів, але що може бути причиною цієї пошкодження та чи є вона взагалі ймовірною?

Безумовно, файл не буде пошкоджений помилками передачі, оскільки вони виявлені мережевим протоколом. І звичайно, будь-який зловмисник, який міг би змінити файл для зловмисних цілей, також міг змінити контрольну суму. Чи перевіряємо помилки на жорсткому диску? Чи частіше це трапляється при написанні, то при читанні? Я пропускаю щось важливе?

Виявити корупцію не зовсім коректно. Для перевірки цілісності програмного забезпечення було б більш правильним використанням. Зазвичай програмне забезпечення не поширюється з одного сервера. Одне програмне забезпечення може поширюватися з багатьох серверів. Отже, коли ви завантажуєте певне програмне забезпечення, для збільшення швидкості завантаження вибирається найближчий до вашого пункту призначення сервер. Однак цим "неофіційним" (стороннім) серверам не завжди можна довіряти. Вони можуть / можуть включати в програму троянів / вірусів / рекламного ПЗ /, що не годиться .

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

Приклад взято з Практичного Unix та Інтернет-безпеки

MD5 (у синьому полі є 1500 доларів.) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (у синьому полі є 1100 доларів.) = D6dee11aae89661a45eb9d21e30d34cb

Повідомлення, які відрізняються лише одним символом (а всередині цього символу - лише одним бінарним бітом), мають абсолютно різні дайджести повідомлень.

Якщо завантажений файл має ту саму контрольну суму, що і контрольна сума, наведена на "офіційному" веб-сайті, програмне забезпечення можна вважати таким, що не змінюється.

Бічна примітка: теоретично два різні файли МОЖУТЬ мати однакове хеш-значення. Щоб алгоритм хеш-контрольної суми вважався безпечним, обчислювально слід дуже дорого знайти інший файл, який створює ту саму контрольну суму.

І звичайно, будь-який зловмисник, який міг би змінити файл для шкідливих цілей, також міг змінити контрольну суму.

Не завжди.

Ви можете мати посилання на вміст разом із контрольною сумою, що подається на HTTPS. Посилання може бути незашифрованим посиланням - звичайним HTTP або FTP, або чимось іншим.

З іншого боку, незашифроване з'єднання може стати легко середнім, а вгорі може бути швидшим або зручнішим для веб-майстра (менше необхідних обчислювальних ресурсів та можливостей мережі кешувати цей матеріал).

Якщо контрольна сума подається на безперервне надійне з'єднання і корисна навантаження відповідає контрольній сумі, ви отримуєте найкращі з обох світів (за умови, що контрольна сума криптографічно захищена).

Це означає, що ви нагадали мені, що там є дистрибутиви, які заявляють, що вони "захищені", і все ж їхній веб-сайт є лише на HTTP, як і посилання на їх зображення.

Приклади:

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

Це щось смішно, тому що ти не можеш отримати більш незахищеного цього. Навіть якщо вони самі не шкідливі, будь-який Інтернет-провайдер може легко замінити і веб-сайт, і зображення підробками, і змусити когось встановити сфальсифіковану операційну систему, роблячи так, що вони отримують "безпечний" дистрибутив Linux - це найкраща підкорений.

Що стосується того, чому перевірка помилок TCP / IP не охоплює все: Від /programming//a/17083365/2551539

Можуть траплятися різні помилки (які виявить TCP) [вказував Джейкоб Кралл] :

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

Відредагуйте додаткову інформацію:

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

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

Апаратну помилку клієнта, наприклад, пошкодження диска, навряд чи можна буде виявити, перевіривши відразу після завантаження, оскільки контрольна сума буде розрахована з кешованої копії. Перевірка завантажувальних медіа на предмет корупції, якщо вони не змогли завантажуватись, корисна, з іншого боку - ви дійсно перевіряєте носій, і у вас є припущення, що обладнання може бути поганим.

Справжня причина для обчислення контрольних сум - це насправді виявлення помилок на рівні програмного забезпечення. Це трапляється. Можливі помилки включають:

• Частково завантажено файл. Веб-сервери та браузери, як правило, погано виявляють перервані з'єднання та очищення часткових файлів. Помилка може бути під час завантаження, або це могло бути під час завантаження, вона додається.
• По дорозі була якась корупція. Наприклад, деякий проміжний вузол у розподілі файлу вирішив застосувати перетворення кодування тексту до двійкового файлу. Або якийсь неправильно налаштований сервер подав повідомлення про помилку замість вмісту.
• Варіант: невірно завантажений файл.
• Рідкісний, але може бути корисним для захисту від: противник змінив файл, але не зміг змінити контрольну контрольну суму. Інфраструктури безпеки, як правило, ускладнюють зловмиснику розповсюдження недійсної контрольної суми, ніж недійсний файл. Наприклад, великі файли часто поширюються за допомогою дзеркал, тоді як контрольні суми обслуговуються центральним сайтом з меншими можливостями для невмілих дій (доступ до сервера лише для лідерів проектів, розповсюдження через HTTPS).

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

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

Насправді комп'ютери - це машини та програмне забезпечення, обидва з яких розроблені та побудовані помилковими людьми. У випадку, якщо завантаження якимось чином не підходить з тієї чи іншої причини, як-от завантаження через якийсь посередницький пристрій, невинний чи нечесний, який обробляє дані, непогано мати спосіб перевірити, що файл майже напевно був завантажується як точна репліка файлу на стороні постачальника.

Якісна контрольна сума є надійним методом перевірки цілісності даних.

Жодна контрольна сума не може бути 100% надійною, оскільки багато файлів відображаються в одній контрольній сумі.

Коли ми додаємо ще одну контрольну суму до поїзда, ми множимо ймовірність виявлення помилки.

В Інтернеті так багато трафіку, що помилки насправді є досить поширеними.

Checksum також допоможе запобігти пошкодженню завантаження через таку ситуацію:

Сервер має внутрішню помилку під час обслуговування завантаження, отже, завантаження припиняється.

Коли це відбувається, є кілька можливих результатів:

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

Я бачив подібну поведінку серед популярних клієнтських інструментів та серверних рамок, тому коли ви не використовуєте контрольну суму, то у випадку "хороший сервер + поганий клієнт" або "поганий сервер + будь-який клієнт", ваше пошкоджене завантаження буде непоміченим .