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

16

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?

tcp

— Aditya K
source

10

N'oubliez pas non plus d'éventuels bogues dans les logiciels et le matériel effectuant le transfert de données, sur les points de terminaison comme entre les deux.

— sebix

Le téléchargement s'est peut-être terminé quelques octets plus tôt. Vous ne le remarqueriez pas nécessairement par la taille du fichier, sauf si vous y prêtez attention, et la correction d'erreur TCP n'aurait vérifié que la partie des données qui est réellement arrivée.

— Kevin Keane

Les sommes de contrôle peuvent être utiles mais, en 20 ans de travail avec les ordinateurs, je ne me souviens pas l'avoir utilisé une fois.

— Pedro Lobito

2

MD5 sont des hachages, pas des sommes de contrôle. Une somme de contrôle est utilisée pour vérifier les erreurs, en particulier les erreurs de bits pendant la transmission. Un hachage cryptographique est destiné à garantir que les données sont exactement les mêmes. En ce sens, un hachage serait un surensemble de somme de contrôle, mais ce n'est pas la même chose. En plus de cela, MD5 est en panne depuis 10 ans maintenant (voir l'article Wikipedia, section Sécurité ).

— 0xC0000022L

20

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.

— Håkan Lindqvist
source

Meilleure réponse! Je déteste la façon dont les autres réponses mélangent les concepts de hachages cryptographiques et de sommes de contrôle.

— 0xC0000022L

20

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.

— Konrad Gajewski
source

21

Cela signifie également qu'il est raisonnablement sûr de télécharger une image ISO à partir d'un site miroir aléatoire, à condition que vous obteniez les sommes de contrôle d'un endroit fiable; par exemple, un post signé PGP sur la liste de diffusion foo-announce.

— richardb

2

Cela n'a en fait rien à voir avec la protection contre les activités malveillantes. Si l'ISO aurait pu être remplacée par une image malveillante, la valeur de la somme de contrôle MD5 pourrait également l'être. Les faire signer est une question différente, mais pas ce que le PO demande. Ainsi, au lieu de "l'activité malveillante" en premier sur votre liste (cela semble sûr bon), il ne devrait même pas être sur votre liste. Vous donnez aux gens un faux sentiment de sécurité, ce qui est dangereux. superuser.com/questions/849845/…

— Austin '' Danger '' Pouvoirs

1

@ Austin''Danger''Powers Umm, non, Konrad a raison. D'une part, le miroir de téléchargement est généralement différent du site affichant la somme de contrôle, et deuxièmement, il y a beaucoup de FAI dans le monde qui manipulent le trafic - les sommes de contrôle TCP seront correctes, mais vous téléchargez un fichier différent. Et bien sûr, il manque également un autre point - le fichier a peut-être été corrompu sur le serveur, après la création de la somme de contrôle. Cela arrive tout le temps, en particulier pour les serveurs les plus "amateurs" (sans configuration RAID appropriée, etc.).

— Luaan

2

Une réponse à partir de 2015 devrait informer contre hash MD5 . Cet algorithme est cassé depuis dix ans (pas d'exagération!). En outre, vous mélangez la somme de contrôle et le hachage. Ce sont deux choses différentes avec une intention différente derrière elles.

— 0xC0000022L

1

Ajouter pour ajouter au commentaire par @ 0xC0000022L SHA1 est préférable d'éviter si la sécurité est déjà une préoccupation majeure, bien que lui et MD5 soient parfaitement adéquats pour se défendre contre la corruption accidentelle.

— David Spillett

6

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

— Daniel
source

8

Je pense que "garantit l'intégrité des données", c'est vraiment trop vendre ce qu'il fait réellement. Il essaie de vérifier l'intégrité des données avec une approche très allégée, qui n'est pas particulièrement solide.

— Håkan Lindqvist

6

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.

— marque
source

6

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

— Rena
source

2

Sources: * security.stackexchange.com/questions/70970/… * adblockplus.org/forum/viewtopic.php?t=8156 "Agressif FAI injecté / scripts / annonces intégrés bloquables " * iamsrijit.wordpress.com/2012/09/ 14 /… * d'autres peuvent être trouvés facilement sur Google, mais ce n'est pas vraiment sur le sujet ici

— Rena

2

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é...

— David Thomson
source

2

Windows affiche le nombre d'octets différemment de la façon dont Linux le montre? Vraiment? Je pensais que l'abdomen avait disparu avec le système de fichiers de taille de fichier en tant que blocs de CP / M. (Maintenant, si vous regardez autre chose que le nombre d' octets - par exemple, la taille du fichier dans l'Explorateur - cela peut très bien différer. Mais aucun sysadmin sensé ne devrait vérifier l'intégrité du fichier téléchargé de cette façon, c'est donc un problème.) Les octets sont des octets. Le regarder en termes de bits n'a cependant aucun sens; À quand remonte la dernière fois que vous avez téléchargé et stocké un demi-octet?

— un CVn

2

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.

— Fernando Cordeiro
source