Веб-сайты, предоставляющие файлы ISO для загрузки, часто предоставляют контрольные суммы md5 этих файлов, которые мы можем использовать для подтверждения того, что файл загружен правильно и не был поврежден.
Зачем это нужно? Конечно, свойств исправления ошибок TCP достаточно. Если пакет получен неправильно, он будет передан повторно. Разве сама природа соединения TCP/IP не гарантирует целостность данных?
решение1
Как уже отмечалось, существует множество возможностей повреждения данных, когда никакая контрольная сумма на транспортном уровне не может помочь, например, повреждение, происходящее еще до вычисления контрольной суммы на отправляющей стороне, перехват и изменение потока MITM (как данных, так и контрольных сумм), повреждение, происходящее после проверки контрольной суммы на принимающей стороне и т. д.
Если мы проигнорируем все эти другие возможности и сосредоточимся на спецификеКонтрольная сумма TCPи что он на самом деле делает с точки зрения проверки целостности данных, оказывается, что свойства этой контрольной суммы совсем не являются исчерпывающими с точки зрения обнаружения ошибок. То, как был выбран этот алгоритм контрольной суммы, скорее отражает требование скорости в сочетании с периодом времени (конец 1970-х).
Вот какКонтрольная сумма TCPрассчитывается:
Контрольная сумма: 16 бит
Поле контрольной суммы представляет собой 16-битное дополнение до единицы суммы дополнений до единицы всех 16-битных слов в заголовке и тексте. Если сегмент содержит нечетное количество октетов заголовка и текста для контрольной суммы, последний октет дополняется справа нулями для формирования 16-битного слова для целей контрольной суммы. Дополнение не передается как часть сегмента. При вычислении контрольной суммы само поле контрольной суммы заменяется нулями.
Это означает, что любое повреждение, которое уравновешивается при суммировании данных таким образом, останется незамеченным. Существует ряд категорий повреждения данных, которые это позволит, но просто в качестве тривиального примера: изменение порядка 16-битных слов всегда останется незамеченным.
На практике он ловит много типичных ошибок, но совсем не *гарантирует* целостность. Этому также способствует то, что уровень L2 также выполняет проверки целостности (например, CRC32 кадров Ethernet), хотя и только для передачи по локальному каналу, и многие случаи поврежденных данных даже не передаются в стек TCP.
Проверка данных с использованием сильного хэша или, что предпочтительнее, криптографической подписи, находится на совершенно другом уровне с точки зрения обеспечения целостности данных. Эти два варианта едва ли можно даже сравнивать.
решение2
Вероятно, существует миллион причин, по которым следует проверять md5sum, но мне на ум приходят несколько:
- Вредоносная активность — ваш ISO-образ мог быть подделан по пути с сервера.
- Сама страница подделана (лучше всего иметь подписанные md5sums :) )
- Прерванная загрузка (несмотря на исправление ошибок TCP) (проверьтеэтотвне)
- ISO записан неправильно
И в любом случае это займет всего несколько секунд.
решение3
TCP/IP гарантирует целостность данных*. Но он не гарантирует, что 100% файла загружено. Может быть много причин, по которым это может произойти. Например: возможно, вы можете смонтировать ISO, в котором где-то в середине пропущен один или два байта. У вас не будет с этим проблем, пока вам не понадобится один или два конкретных файла, которые повреждены. Сравнение контрольных сумм гарантирует, что вы действительно загрузили весь файл.
* см. комментарий
решение4
Существует несколько причин для проверки контрольной суммы файла, загруженного по протоколу HTTP:
- Обеспечение получения вами всего файла
- Некоторые клиенты, такие какFire Fox, может считать прерванное соединение успешной загрузкой, оставляя вас с обрезанным файлом, но утверждая, что загрузка прошла успешно
- Обеспечение получения вами правильного файла
- например, неисправный, скомпрометированный или вредоносный сервер может отправить вам что-то другое
- кто-то может вмешаться в передачу данных (атака «человек посередине») — даже HTTPS не защищен от этого, если ваша система скомпрометирована, например, Superfish, или используемый метод шифрования слаб.
- Они также могут просто предоставить вам ложную страницу загрузки, так что вы даже не подключитесь к настоящему серверу (но в этом случае контрольные суммы не помогут, если вы получите их с того же поддельного сервера).
- Ряд интернет-провайдеров были уличены во внедрении Javascript в страницы при передаче по разным причинам1 ; в зависимости от того, насколько хорошо это реализовано, это может также испортить загрузку некоторых файлов.
- Зеркало может содержать устаревшую версию файла, или администратор мог загрузить не тот файл.
- Обеспечение того, чтобы файл не был поврежден чем-то, что TCP не может обнаружить
- например, файл может быть поврежден на сервере, поэтому TCP только гарантирует, что уже поврежденный файл не будет дополнительно искажен при передаче.
- или он мог быть поврежден после доставки вам из-за неисправной памяти/диска, глючного драйвера файловой системы и т. д.
- Контрольные суммы TCP имеют длину всего 16 бит, поэтому вероятность того, что поврежденный пакет не будет обнаружен, не астрономическая (1 из 65536).
- С помощью ISO-образа, убедитесь, что диск записан правильно
1 источник в комментарии, потому что lol rep