Pourquoi calculer les sommes de contrôle des fichiers téléchargés?

Je vois souvent une somme de contrôle donnée à côté d'un fichier disponible en téléchargement. Le but de cette pratique m'échappe. Il s'agit bien évidemment de détecter des fichiers corrompus, mais quelle pourrait être la cause de cette corruption et est-ce probable?

Le fichier ne sera sûrement pas endommagé par des erreurs de transmission car celles-ci sont détectées par le protocole réseau. Et sûrement, tout attaquant qui pourrait altérer le fichier à des fins malveillantes pourrait également modifier la somme de contrôle donnée. Vérifions-nous les erreurs de disque dur? Ces risques sont-ils plus susceptibles de se produire lors de l'écriture que lors de la lecture? Suis-je en train de manquer quelque chose d'important?

Détecter la corruption n'est pas tout à fait correct. Vérifier l'intégrité du logiciel serait une utilisation plus correcte. Normalement, un logiciel n'est pas distribué à partir d'un seul serveur. Le même logiciel peut être distribué à partir de nombreux serveurs. Ainsi, lorsque vous téléchargez un logiciel particulier, le serveur le plus proche de votre destination est choisi comme source de téléchargement pour augmenter la vitesse de téléchargement. Cependant, ces serveurs «non officiels» (tiers) ne peuvent pas toujours être approuvés. Ils peuvent / peuvent inclure des chevaux de Troie / virus / adwares / backdoors dans le programme, ce qui n'est pas bon .

Ainsi, pour s'assurer que le logiciel téléchargé est exactement le même que celui du logiciel «officiel» publié par l'organisation concernée, la somme de contrôle est utilisée. Les algorithmes utilisés pour générer des sommes de contrôle sont tels que même un léger changement dans le programme entraîne une somme de contrôle entièrement différente.

Exemple tiré d' Unix pratique et d'Internet Security

MD5 (il y a 1500 $ dans la boîte bleue.) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (Il y a 1100 $ dans la boîte bleue.) = D6dee11aae89661a45eb9d21e30d34cb

Les messages, qui ne diffèrent que par un seul caractère (et, à l'intérieur de ce caractère, par un seul bit binaire), ont des résumés de messages complètement différents.

Si le fichier téléchargé a la même somme de contrôle que la somme de contrôle indiquée sur le site Web «officiel», le logiciel peut être supposé non modifié.

Note latérale: En théorie, deux fichiers différents PEUVENT avoir la même valeur de hachage. Pour que l'algorithme de hachage / somme de contrôle soit considéré comme sûr, il devrait être très coûteux en termes de calcul de trouver un autre fichier qui produit la même somme de contrôle.

Et sûrement, tout attaquant qui pourrait altérer le fichier à des fins malveillantes pourrait également modifier la somme de contrôle donnée.

Pas toujours.

Vous pouvez avoir un lien de contenu avec une somme de contrôle diffusée sur HTTPS. Le lien peut être un lien non crypté - HTTP ou FTP ordinaire, ou autre chose.

À la baisse, la connexion non chiffrée peut facilement être occupée par des intermédiaires, à la hausse, elle peut être plus rapide ou plus pratique pour le webmaster (moins de ressources informatiques nécessaires et la possibilité pour le réseau de mettre en cache ce genre de choses).

Si la somme de contrôle est servie sur une connexion de confiance ininterrompue et que la charge utile correspond à la somme de contrôle, vous obtenez le meilleur des deux mondes (à condition que la somme de contrôle soit cryptographiquement sécurisée).

Cela dit, vous m'avez rappelé qu'il existe des distributions qui prétendent être «sécurisées» et pourtant leur site Web est uniquement sur HTTP, tout comme les liens vers leurs images.

Exemples:

• http://www.networksecuritytoolkit.org/nst/index.html
• http://std.org/download.html

C'est assez drôle parce que vous ne pouvez pas obtenir plus d'insécurité que ça. Même s'ils ne sont pas eux-mêmes malveillants, tout FAI pourrait facilement remplacer à la fois le site Web et l'image par des contrefaçons, et amener quelqu'un à installer un système d'exploitation truqué tout en donnant l'impression qu'ils obtiennent une distribution Linux "sécurisée" est l'ultime pwnage.

En ce qui concerne les raisons pour lesquelles la vérification des erreurs TCP / IP ne capture pas tout: à partir de /programming//a/17083365/2551539

Différentes erreurs peuvent survenir (que TCP détectera) [souligné par Jacob Krall] :

• Ordre incorrect des paquets
• Perte de paquets
• Données corrompues à l'intérieur du paquet
• Paquets fantômes (le récepteur reçoit des paquets qui n'ont jamais été envoyés)

Modifiez avec quelques informations supplémentaires:

La page 9 de cette étude: http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf suggère qu'il existe des erreurs qui peuvent ne pas être détectées par TCP. Ma compréhension est que cela se produit lorsqu'un datagramme erroné (appelé "mauvais jumeau" dans l'étude) a la même somme de contrôle que le datagramme prévu (appelé "bon jumeau" dans l'étude).

Des erreurs de transmission peuvent survenir. Les protocoles de couche liaison contiennent généralement des sommes de contrôle ou des codes de correction d'erreurs pour les éviter, mais ils ne sont pas parfaits: il y a une petite chance qu'une erreur ne soit pas corrigée. Les paquets TCP contiennent également une somme de contrôle, ce qui réduit la probabilité d'erreurs de 2 ^ 16. Cela fait une probabilité très petite mais non nulle d'erreur de transmission. C'est le genre de chose que la plupart des gens ne rencontreront jamais sans le savoir au cours de leur vie, mais ce n'est pas dans la plage de probabilités jamais-en-un-milliard d'années de sommes de contrôle cryptographiques.

Il est peu probable qu'une erreur matérielle sur le client, telle qu'une corruption de disque, soit détectée en vérifiant juste après le téléchargement, car la somme de contrôle sera calculée à partir de la copie mise en cache. En revanche, il est utile de vérifier la corruption du support de démarrage s'il n'a pas réussi à démarrer.Vous testez vraiment le support et vous supposez que le matériel peut être défectueux.

La vraie raison de calculer des sommes de contrôle est en fait de détecter des erreurs de niveau logiciel. Cela arrive. Les erreurs possibles incluent:

• Un fichier a été partiellement téléchargé. Les serveurs Web et les navigateurs ont tendance à mal détecter les connexions interrompues et à nettoyer les fichiers partiels. L'erreur pourrait être pendant votre téléchargement, ou elle pourrait avoir été pendant le téléchargement, ajoute-t-elle.
• Il y a eu de la corruption en cours de route. Par exemple, un nœud intermédiaire dans la distribution du fichier a décidé d'appliquer une conversion d'encodage de texte à un fichier binaire. Ou un serveur mal configuré a envoyé un message d'erreur au lieu du contenu.
• Une variante: le mauvais fichier a été téléchargé.
• Rare, mais peut être utile pour se protéger contre: un adversaire a modifié le fichier mais n'a pas pu modifier la somme de contrôle de référence. Les infrastructures de sécurité ont tendance à rendre plus difficile pour un attaquant de propager une somme de contrôle non valide qu'un fichier non valide. Par exemple, les fichiers volumineux sont souvent distribués via des miroirs, tandis que les sommes de contrôle sont servies par un site central avec moins de possibilités de falsification (accès serveur uniquement aux chefs de projet, distribution via HTTPS).

En pratique, la vérification de la taille du fichier téléchargé détecte les erreurs les plus courantes, qui sont des fichiers tronqués ou convertis de manière incorrecte. Les sommes de contrôle ont l'avantage de détecter strictement plus de problèmes.

En théorie, le réseau fournirait correctement chaque segment et ils seraient correctement assemblés sur le disque et rien ne se passerait mal.

En réalité, les ordinateurs sont des machines et des logiciels, tous deux conçus et construits par des humains faillibles. Dans le cas où un téléchargement ne se déroule pas correctement pour une raison ou une autre, comme le téléchargement via un appareil intermédiaire, qu'il soit inoffensif ou néfaste qui gâche les données, il est agréable d'avoir un moyen de vérifier que le fichier était presque certainement téléchargé comme une réplique précise du fichier du côté du fournisseur.

Une somme de contrôle de haute qualité est une méthode fiable pour valider l'intégrité des données.

Aucune somme de contrôle ne peut être fiable à 100% car de nombreux fichiers sont mappés sur la même somme de contrôle.

Lorsque nous ajoutons une autre somme de contrôle au train, nous multiplions la probabilité de détecter une erreur.

Il y a tellement de trafic sur Internet que les erreurs sont en fait assez courantes.

La somme de contrôle aidera également à empêcher le téléchargement corrompu en raison de la situation suivante:

Le serveur a une erreur interne lors du traitement du téléchargement, le téléchargement est donc terminé.

Lorsque cela se produit, il y a quelques résultats possibles:

• Bon serveur - l'implémentation par le serveur de l' encodage de transfert Chunked n'est pas buggée:
  • Un bon client (comme cURL, wget) pourra vous informer qu'il s'agit d'un téléchargement incorrect car le bloc de terminaison n'a jamais été envoyé depuis le serveur.
  • Un client incorrect pensera que le téléchargement est terminé car aucune donnée n'est reçue du serveur.
• Mauvais serveur - l'implémentation par le serveur de l' encodage de transfert par blocs est boguée car elle envoie le bloc de terminaison pour ce mauvais téléchargement:
  • Tout client pensera que ce téléchargement s'est terminé avec succès.

J'ai vu ces comportements parmi les outils client et les infrastructures de serveur populaires, donc lorsque vous n'utilisez pas la somme de contrôle, dans le cas de "bon serveur + mauvais client" ou "mauvais serveur + n'importe quel client", votre téléchargement corrompu sera inaperçu .