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

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

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

 15
додано Змінено
Перегляди: 25
джерело
ro nl ja ru fr es pt de hi bn ar kk uz be tr
MD5 - це хеші, а не контрольні суми. Контрольна сума використовується для перевірки на наявність помилок, зокрема помилок в бітах під час передачі. Криптографічний хеш призначений для забезпечення того, щоб дані були абсолютно однаковими. У цьому сенсі хеш був би набором контрольної суми, але вони не збігаються. Окрім цього, MD5 було порушено 10 років (див. Статтю статтю Вікіпедії) , розділ Безпека ).
додано Автор 0xC0000022L, джерело
Також не забувайте про можливі помилки в програмному забезпеченні та апаратних засобах, які роблять передачу даних, на кінцевих точках, а також між ними.
додано Автор perror, джерело
Завантаження може закінчитися на кілька байт рано. Ви не обов'язково помітите це за розміром файлу, якщо ви не звернете увагу, а виправлення помилок TCP лише перевірило б частину даних, які дійсно прибули.
додано Автор Kevin Keane, джерело
Контрольні суми можуть бути зручними, але через 20 років роботи з комп'ютерами я не пам'ятаю, як використовувати її один раз.
додано Автор Pedro Lobito, джерело

7 Відповіді

Є, мабуть, мільярд причин, чому треба перевіряти md5sum, але деякі з них приходять на думку

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

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

20
додано
джерело
Щоб додати до коментаря @ 0xC0000022L, краще уникати SHA1, якщо безпека є головним занепокоєнням, хоча і вона, і MD5 цілком достатні для захисту від випадкової корупції.
додано Автор Ryan Clemmons, джерело
Відповідь від 2015 року радить щодо хешей MD5 . Цей алгоритм був розбитий протягом останніх десяти років (без перебільшення!). Крім того, ви змішуєте контрольну суму і хеш. Це дві різні речі з різними намірами за ними.
додано Автор 0xC0000022L, джерело
Це насправді не має нічого спільного з захистом від шкідливої ​​діяльності. Якщо ISO можна було б замінити на зловмисне, так само може бути значення контрольної суми MD5. Підписання їх - це інша справа, але не те, про що питає ОП. Таким чином, замість того, щоб "злоякісна діяльність" була першою у вашому списку (це дійсно добре звучить), вона насправді не повинна бути у вашому списку. Ви даєте людям помилкове почуття безпеки, яке є небезпечним. superuser.com/questions/849845/…
додано Автор Austin ''Danger'' Powers, джерело
@ Austin''Danger''Powers Umm, ні, право Konrad. По-перше, дзеркало для завантаження, як правило, відрізняється від сайту, що показує контрольну суму, і по-друге, у світі існує досить багато провайдерів, які маніпулюють трафіком - контрольні суми TCP будуть нормальними, завантаження іншого файлу. І, звичайно ж, йому також не вистачає іншого пункту - файл може бути пошкоджений на сервері після створення контрольної суми. Це відбувається весь час, особливо для більш «любителів» серверів (без належних налаштувань RAID тощо).
додано Автор eshowcase, джерело
Надішліть автору повідомлення SHA1 електронною поштою. А також переконайтеся, що він не підміняється. Дякуємо за ваші коментарі. Але я був би вдячний, якщо б ви розширили їх на відповіді. Таким чином я (і решта чудових людей тут) могли щось навчитися і вміти розробляти.
додано Автор Konrad Gajewski, джерело
Це також означає, що це достатньо безпечно для завантаження ISO з випадкового дзеркального сайту, за умови, що ви отримаєте контрольні суми з надійного місця; наприклад, PGP підписав повідомлення до списку розсилки foo-announce.
додано Автор bG1NN3R, джерело

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

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

Таким чином розраховується контрольна сума TCP .

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

     

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

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


In practice, it catches many typical errors but does not at all guarantee integrity. It's also helped by how the L2 layer also does integrity checks (eg CRC32 of Ethernet frames), albeit only for the transmission on the local link, and many cases of corrupted data never even get passed to the TCP stack.

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

19
додано
джерело
Найкраща відповідь! Я ненавиджу, як інші відповіді змішують поняття криптографічних хешей і контрольних сум.
додано Автор 0xC0000022L, джерело

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

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

6
додано
джерело
Я думаю, що "гарантує цілісність даних" - це дійсно надмірно продає те, що вона насправді робить. Це робить спробу перевірити цілісність даних дуже підходом, який не є особливо сильним.
додано Автор Jacob, джерело

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

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

6
додано
джерело

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

  • Ensuring you received the entire file
    • Some clients, such as Firefox, may treat an interrupted connection as a successful download, leaving you with a truncated file but claiming it downloaded OK
  • Ensuring you received the correct file
    • e.g. a buggy, compromised or malicious server might send you something else
    • someone could tamper with the transfer (man-in-the-middle attack) - even HTTPS isn't safe from this if your system is compromised by e.g. Superfish, or the encryption method being used is weak
    • They might also just present you with a false download page, so you're not even connected to the real server (but in this case the checksums won't help much if you get them from the same fake server)
    • A number of ISPs have been caught injecting Javascript into pages in transmission for various reasons1; depending how well this is implemented, it might mangle some file downloads as well
    • A mirror might be hosting an out-of-date version of the file, or the admin might have uploaded the wrong file
  • Ensuring the file wasn't corrupted by something that TCP can't detect
    • e.g. the file could be corrupted on the server, so TCP will only ensure that the already corrupted file didn't get further mangled in transmission
    • or it could be corrupted after arriving on your end, by faulty memory/disk, buggy filesystem driver, etc
    • TCP checksums are only 16-bit, so the chances aren't astronomical (1 in 65536) that a corrupted packet won't be detected
  • With an ISO, ensuring that the disc burned correctly

1 sources in comment because lol rep

6
додано
джерело
Джерела: * security.stackexchange.com/questions/70970/… * adblockplus.org/forum/viewtopic.php?t=8156 "Агресивні ISP вбудовані/вбудовані скрипти/оголошення блокуються" * iamsrijit.wordpress.com/2012/09/14/… * більше можна знайти легко на Google, але це не дуже актуально
додано Автор Rena, джерело

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

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

2
додано
джерело
Windows показує кількість байтів по-різному від того, як це показує Linux? Дійсно? Я думав, що абдомінація вийшла з файловою системою розміру файлу CP-M-as-blocks-count. (Тепер, якщо ви шукаєте щось інше, ніж байт - скажімо, розмір файлу відображається в Провіднику - він може відрізнятися. Таким чином, це не проблема.) Байти - це байти. Дивлячись на нього з точки зору біт не має сенсу, хоча; коли останній раз ви завантажували і зберігали половину байта?
додано Автор Michael Kjörling, джерело

I notice lots of interesting answers but there is a last thing to consider:Two Generals' Problem

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

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

2
додано
джерело