Pourquoi est-il recommandé de comparer les sommes de contrôle lors du téléchargement d'un fichier?

Les sites Web qui fournissent des fichiers ISO à télécharger donnent souvent les sommes de contrôle md5 de ces fichiers, que nous pouvons utiliser pour confirmer que le fichier a été téléchargé correctement et qu'il n'a pas été corrompu.

Pourquoi est-ce nécessaire? Certes, les propriétés de correction d'erreur de TCP sont suffisantes. Si un paquet n'est pas reçu correctement, il sera retransmis. La nature même d'une connexion TCP / IP ne garantit-elle pas l'intégrité des données?

Comme cela a été noté par d'autres, il existe de nombreuses possibilités de corruption de données où toute somme de contrôle au niveau de la couche de transport ne peut pas aider, comme une corruption qui se produit déjà avant que la somme de contrôle soit calculée du côté de l'envoi, un MITM interceptant et modifiant le flux (données également en tant que sommes de contrôle), la corruption se produit après avoir validé la somme de contrôle à l'extrémité de réception, etc.

Si nous ignorons toutes ces autres possibilités et nous concentrons sur les spécificités de la somme de contrôle TCP elle-même et sur ce qu'elle fait réellement en termes de validation de l'intégrité des données, il s'avère que les propriétés de cette somme de contrôle ne sont pas du tout complètes en termes de détection d'erreurs. La façon dont cet algorithme de somme de contrôle a été choisi reflète plutôt l'exigence de vitesse en combinaison avec la période de temps (fin des années 1970).

Voici comment la somme de contrôle TCP est calculée:

Somme de contrôle: 16 bits

Le champ de somme de contrôle est le complément à un sur 16 bits de la somme du complément à un de tous les mots de 16 bits dans l'en-tête et le texte. Si un segment contient un nombre impair d'octets d'en-tête et de texte à additionner, le dernier octet est complété à droite par des zéros pour former un mot de 16 bits à des fins de somme de contrôle. Le pad n'est pas transmis dans le cadre du segment. Lors du calcul de la somme de contrôle, le champ de somme de contrôle lui-même est remplacé par des zéros.

Cela signifie que toute corruption qui s'équilibre lors de la sommation des données de cette manière ne sera pas détectée. Il y a un certain nombre de catégories de corruption dans les données que cela permettra mais juste comme un exemple trivial: changer l'ordre des mots de 16 bits restera toujours non détecté.

En pratique, il détecte de nombreuses erreurs typiques mais ne garantit pas du tout l' intégrité. Cela est également aidé par la façon dont la couche L2 effectue également des vérifications d'intégrité (par exemple, CRC32 des trames Ethernet), mais uniquement pour la transmission sur la liaison locale, et de nombreux cas de données corrompues ne sont même jamais transmis à la pile TCP.

La validation des données à l'aide d'un hachage fort, ou de préférence d'une signature cryptographique, est à un tout autre niveau en termes de garantie de l'intégrité des données. Les deux sont à peine comparables.

Il y a probablement un million de raisons pour lesquelles on devrait vérifier la somme md5, mais quelques-unes me viennent à l'esprit:

• Activité malveillante - votre ISO aurait pu être falsifiée sur le chemin du serveur
• La page elle-même est usurpée (il est préférable de faire également signer les sommes md5 :))
• Téléchargement cassé (malgré la correction d'erreur TCP) (vérifiez ceci )
• ISO brûlé incorrectement

Et cela ne prend que quelques secondes de toute façon.

TCP / IP garantit l'intégrité des données *. Mais cela ne garantit pas que 100% d'un fichier a été téléchargé. Il peut y avoir de nombreuses raisons pour lesquelles cela pourrait se produire. Par exemple: Il est possible que vous puissiez monter un ISO qui manque un ou deux octets quelque part au milieu. Vous n'aurez aucun problème avec cela jusqu'à ce que vous ayez besoin d'un ou deux fichiers particuliers qui sont corrompus. La comparaison des sommes de contrôle garantit que vous avez réellement téléchargé l'intégralité du fichier.

* voir commentaire

La somme de contrôle TCP n'est que de 16 bits. Cela signifie qu'en l'absence d'autres sommes de contrôle, un paquet corrompu sur 65536 sera accepté comme non corrompu. Si, par exemple, vous téléchargiez une image DVD de 8 Go via un lien bruyant avec un taux de corruption de 1%, vous vous attendriez à 81 paquets indétectablement corrompus.

MD5 est une somme de contrôle beaucoup plus grande, à 128 bits. La probabilité que ces 81 paquets produisent quelque chose avec la même somme de contrôle que l'original est d'environ 1 sur 1 000 000 000 000 000 000 000 000 000 000 000.

Il y a plusieurs raisons de vérifier la somme de contrôle d'un fichier téléchargé via HTTP:

• S'assurer d'avoir reçu l'intégralité du dossier
  • Certains clients, tels que Firefox , peuvent traiter une connexion interrompue comme un téléchargement réussi, vous laissant un fichier tronqué mais prétendant qu'il a été téléchargé OK
• S'assurer d'avoir reçu le bon fichier
  • par exemple, un serveur bogué, compromis ou malveillant pourrait vous envoyer autre chose
  • quelqu'un pourrait altérer le transfert (attaque de l'homme du milieu) - même HTTPS n'est pas à l'abri de cela si votre système est compromis par exemple par Superfish, ou si la méthode de cryptage utilisée est faible
  • Ils pourraient également vous présenter une fausse page de téléchargement, de sorte que vous n'êtes même pas connecté au vrai serveur (mais dans ce cas, les sommes de contrôle ne seront pas très utiles si vous les obtenez du même faux serveur)
  • Un certain nombre de FAI ont été surpris en train d'injecter Javascript dans des pages en cours de transmission pour diverses raisons ¹ ; en fonction de la façon dont cela est mis en œuvre, cela pourrait également réduire certains téléchargements de fichiers
  • Un miroir peut héberger une version obsolète du fichier, ou l'administrateur a peut-être téléchargé le mauvais fichier
• S'assurer que le fichier n'a pas été corrompu par quelque chose que TCP ne peut pas détecter
  • Par exemple, le fichier pourrait être corrompu sur le serveur, donc TCP s'assurera seulement que le fichier déjà corrompu n'a pas été altéré lors de la transmission
  • ou il pourrait être corrompu après être arrivé de votre côté, par une mémoire / un disque défectueux, un pilote de système de fichiers bogué, etc.
  • Les sommes de contrôle TCP ne sont que de 16 bits, donc les chances ne sont pas astronomiques (1 sur 65536) qu'un paquet corrompu ne soit pas détecté
• Avec un ISO, garantissant que le disque est gravé correctement

¹ sources en commentaire car lol rep

Daniel, selon l'outil que vous utilisez pour le téléchargement ISO par exemple. Si c'est Say Firefox .. Il peut montrer le téléchargement du fichier. Cependant, vous ne pouvez pas avoir l'intégralité de l'ISO intact. Si vous le gravez puis essayez de l'utiliser, des informations peuvent être manquantes. Cela se produit de temps en temps sur différents serveurs Web hébergeant des fichiers.

Il est recommandé de comparer au moins la taille du fichier (nombre total d'octets ou de bits) pour vous assurer qu'elles correspondent. Windows affichera un nombre d'octets de fichiers différent, puis dira Linux. Le contrôle de somme MD5 affichera les mêmes valeurs quel que soit le système d'exploitation utilisé. J'espère que ça aide un peu. À votre santé...

Je remarque beaucoup de réponses intéressantes mais il y a une dernière chose à considérer: le problème des deux généraux

Le problème des deux généraux et le problème des généraux byzantins examinent spécifiquement les implications d'un transfert fiable d'informations via des canaux peu fiables.

Les sommes de contrôle ne sont qu'une autre couche de "fiabilité croissante", et une avec un très faible risque d'échec. C'est la raison pour laquelle il est si populaire.