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

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

Чому це потрібно? Звичайно, властивості TCP, що виправляють помилки, є достатніми. Якщо пакет отримано неправильно, він буде повторно переданий. Чи не сама природа з'єднання TCP / IP не гарантує цілісність даних?

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

Якщо ми нехтуємо всіма цими іншими можливостями і зосередимось на специфіці самої контрольної суми TCP та тому, що вона насправді робить з точки зору перевірки цілісності даних, виявиться, що властивості цієї контрольної суми зовсім не є вичерпними з точки зору виявлення помилок. Спосіб вибору цього алгоритму контрольної суми швидше відображає вимогу швидкості в поєднанні з періодом часу (кінець 1970-х).

Ось як обчислюється контрольна сума TCP :

Контрольна сума: 16 біт

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

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

На практиці він виявляє багато типових помилок, але зовсім не гарантує цілісності. Допомагає також те, як рівень L2 також здійснює перевірку цілісності (наприклад, CRC32 кадрів Ethernet), хоча і лише для передачі по локальній лінії зв'язку, і багато випадків пошкоджених даних навіть не передаються до стеку TCP.

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

Напевно, є мільйон причин, чому варто перевірити md5sum, але мені спадають на думку декілька:

• Зловмисна активність - ваш ISO може бути підроблений на шляху з сервера
• Сама сторінка підроблена (найкраще, щоб md5sums також були підписані :))
• Помилка завантаження (незважаючи на виправлення помилок TCP) (перевірте це )
• ISO записаний неправильно

І це все одно займає лише кілька секунд.

TCP / IP гарантує цілісність даних *. Але це не гарантує, що 100% файлу було завантажено. Причин, чому це могло статися, може бути багато. Наприклад: Можливо, ви можете встановити ISO, який пропускає один-два байти десь посередині. У вас не буде проблем з цим, поки вам не знадобляться один або два конкретні файли, які є пошкодженими. Порівняння контрольних сум гарантує, що ви дійсно завантажили весь файл.

* див. коментар

Контрольна сума TCP становить лише 16 біт. Це означає, що за відсутності інших контрольних сум один з кожні 65536 зіпсованих пакетів буде прийнятий як некорумпований. Якщо, наприклад, ви завантажували зображення DVD з 8 Гб через галасливе посилання з коефіцієнтом корупції 1%, ви очікували б 81 непомітно зіпсованих пакетів.

MD5 - набагато більша контрольна сума, на 128 біт. Шанс цих 81 пакета, що виробляє щось з тією ж контрольною сумою, що і оригінал, становить приблизно 1 на 1 000 000 000 000 000 000 000 000 000 000 000 000.

Існує кілька причин для перевірки контрольної суми файлу, завантаженого через HTTP:

• Переконайтеся, що ви отримали весь файл
  • Деякі клієнти, такі як Firefox , можуть сприймати перерване з’єднання як вдале завантаження, залишаючи вам усічений файл, але заявляючи, що його завантажено ОК
• Переконайтеся, що ви отримали правильний файл
  • наприклад, баггі, зламаний або шкідливий сервер може надіслати вам щось інше
  • хтось може підробити передачу (атака "людина-посеред") - навіть HTTPS не є безпечним від цього, якщо ваша система порушена, наприклад, Superfish, або метод шифрування, який використовується, слабкий
  • Вони можуть просто представити вам помилкову сторінку завантаження, тому ви навіть не підключені до реального сервера (але в цьому випадку контрольні суми не дуже допоможуть, якщо ви отримаєте їх з того ж підробленого сервера)
  • З різних причин ряд провайдерів спіймали введення Javascript на сторінки при передачі ¹ ; залежно від того, наскільки добре це реалізовано, це може також забруднити деякі завантаження файлів
  • У дзеркалі може бути розміщена застаріла версія файлу, або адміністратор може завантажити інший файл
• Переконайтесь, що файл не був пошкоджений чимось тим, що TCP не може виявити
  • наприклад, файл може бути пошкоджений на сервері, тому TCP лише гарантуватиме, що вже пошкоджений файл не отримав подальших помилок при передачі
  • або вона може бути пошкоджена після того, як ви приїдете до кінця, через несправну пам'ять / диск, помилковий драйвер файлової системи тощо
  • Контрольні суми TCP лише 16-бітні, тому шанси не є астрономічними (1 на 65536), що пошкоджений пакет не буде виявлений
• Із ISO, гарантуючи правильне записування диска

¹ джерела в коментарі, тому що lol респ

Даніель, залежно від інструменту, який ви використовуєте для завантаження ISO за кожну думку. Якщо це Say Firefox .. Це може відобразити завантаження файлу. Однак у вас може бути не повний ISO недоторканим. Якщо ви записали його, то спробуйте використовувати його, інформація може бути відсутня. Час від часу трапляється на різних веб-серверах, що розміщують файли.

Це хороша практика хоча б порівняти розмір файлу (загальний байт чи біт), щоб переконатися, що вони відповідають. Windows покаже, що кількість байтів файлів відрізняється, ніж скажімо, Linux. Перевірка суми MD5 не відображатиме однакові значення, не використовуючи яку ОС. Сподіваюсь, це трохи допомагає. Ура ...

Я помічаю багато цікавих відповідей, але є останнє, що слід врахувати: проблема двох генералів

Проблема двох генералів та проблема візантійських генералів конкретно розглядають наслідки надійної передачі інформації через ненадійні канали.

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