Donc, si vous téléchargez un fichier à partir de ce qui est effectivement une source non authentifiée et que vous le validez avec un hachage de la même source (ou même d'une autre source non authentifiée), quelle est la valeur réelle du hachage du fichier ?

Le hachage fourni vous permet de vérifier que le fichier que vous avez téléchargé n'a pas été corrompu accidentellement pendant le transport, ou que le fichier que vous avez téléchargé depuis une autre source (un miroir plus rapide) est le même que le fichier est disponible en téléchargement sur ce site.

Cependant, il n'y a pas vraiment beaucoup de sécurité supplémentaire. Un cracker suffisamment expérimenté peut remplacer le fichier par une version malicieusement modifiée et le hachage par une qui correspond au fichier modifié; ou il peut MITM les requêtes sur le réseau et remplacer à la fois le fichier demandé par le sien et le hachage par le sien.

Le bénéfice y est en effet limité. Comme vous l'avez souligné, si vous pouvez remplacer une chose sur un site, vous pouvez probablement remplacer les deux.

Cela présente cependant certains avantages:

• Cela permet d'autres sites pour héberger des fichiers volumineux avec une intégrité vérifiée. Avec cela, je peux récupérer le fichier auprès d'une tierce partie aléatoire en qui je n'ai aucune raison de faire confiance et toujours vérifier qu'il s'agit d'un bon fichier basé sur le site source (qui peut avoir une bande passante limitée).
• Si votre site est assez populaire, il est probable qu'il y ait suffisamment de copies de l'ancien hachage pour confirmer rapidement un compromis au public, y compris via archive.org et divers caches des moteurs de recherche.

est une sécurité supplémentaire à gagner en ayant des fichiers de signature avec une paire de clés publique / privée, l'avantage pratique pour la plupart des applications n'est pas plus grand avec une clé que sans. Si je poste ma clé sur le site Web et signe tout au lieu de publier le hachage, un attaquant peut obtenir le même effet en remplaçant la clé qu'en remplaçant le hachage. Les projets à grande échelle qui ont une distribution indépendante ont besoin de cette couche supplémentaire (Debian vient à l'esprit), mais je pense que peu en bénéficieraient.

Pour que le hachage ait une valeur liée à la sécurité, les deux conditions suivantes doivent toutes les deux être remplies:

• la valeur de hachage doit être distribuée via un protocole qui garantit l'intégrité (par exemple HTTPS);
• le fichier téléchargé ne doit pas être distribué via un protocole qui garantit l'intégrité;

car, si le est également servi avec HTTPS, alors le hachage a tendance à être inutile: SSL assure déjà l'intégrité lors du transfert.

Le hachage ne protégera pas contre un attaquant qui prend le contrôle du serveur, car il pourrait alors modifier le hachage comme il pourrait modifier le fichier.

Un exemple de l'utilité du hachage publié est lorsque vous téléchargez le fichier à une certaine date, puis que vous voulez vérifier plus tard sur ce que la copie que vous avez est correcte, parce que vous ne faites pas nécessairement confiance à l'intégrité de votre stockage local (par exemple, il était sur une clé USB qui aurait pu être temporairement volée par une personne mal intentionnée). Un autre exemple est lorsque le téléchargement lui-même provient d'un réseau p2p, car de telles choses sont très efficaces pour distribuer des logiciels en masse à de nombreux clients (c'est ce que fait Blizzard Downloader): utilisez le p2p pour obtenir le fichier, puis obtenez la petite valeur de hachage du site HTTPS principal. Un troisième exemple (que je rencontre professionnellement) est lors de la construction d'un système de confiance dans des conditions d'audit difficiles (par exemple, la création d'une nouvelle autorité de certification racine): vous voulez que l'auditeur puisse vérifier que le logiciel utilisé est authentique . Si un fichier de hachage est distribué (via HTTPS), l'auditeur doit simplement le vérifier par rapport à une archive locale; sinon, l'auditeur doit être témoin de l'intégralité du téléchargement. Compte tenu des tarifs horaires des auditeurs, le hachage est préférable.

Vous avez raison de dire que le simple fait d'avoir un hachage brut présente un avantage limité, car vous devez également le distribuer en toute sécurité, et la plupart des gens ne savent pas comment le vérifier correctement ou naviguer parmi les nombreux problèmes possibles.

La bonne façon d'obtenir une bonne sécurité est d'utiliser la technologie de clé publique pour signer les hachages et de l'intégrer de manière transparente dans l'ensemble du schéma de distribution de logiciels. Il est toujours nécessaire de distribuer en toute sécurité la clé publique, mais cela peut être fait une fois, par ex. lorsque le système d'exploitation est installé. Je suppose que c'est essentiellement ce qui est fait avec Windows et MacOS pour les mises à jour du système d'exploitation et quelques packages majeurs comme Office.

Le mieux, c'est quand presque tous les logiciels dont vous avez besoin sont couverts par les mêmes clés standard. C'est essentiellement ce qui se passe avec la plupart des distributions de logiciels open source, comme Debian, Ubuntu, Red Hat, Suse, etc. Ils distribuent en toute sécurité des dizaines de milliers de paquets, tous automatiquement signés avec des clés qui sont gérées dans le cadre de la distribution, et donc hautement sécurisé. Et cela se produit généralement sans que personne n'ait besoin de faire de vérifications manuelles.

Donc, si vous téléchargez un fichier à partir de ce qui est effectivement une source non authentifiée et que vous le validez avec un hachage de la même source (ou même d'une autre source non authentifiée), quelle est la valeur réelle du hachage du fichier ?

Dans cette situation, où un hachage se trouve immédiatement à côté d'un lien vers le fichier, la valeur est principalement de s'assurer que le fichier n'est pas endommagé ou corrompu pendant le transport.

Du point de vue de la sécurité, vous avez raison; cela a très peu de valeur pour prouver que le fichier n'a pas été falsifié, car toute personne qui pourrait entrer et télécharger un fichier piraté (ou changer le lien pour pointer vers une copie piratée) pourrait également remplacer le hachage qui se trouve à côté. C'est pourquoi ce n'est presque jamais fait de cette façon lorsque l'objectif est la sécurité.

En général, lorsqu'un condensé de hachage est proposé, il vient directement du producteur du logiciel. Ils proposent des logiciels à télécharger, mais ne sont pas disposés à héberger directement le logiciel sur leurs propres serveurs; ils sont une société de logiciels, pas une société d'hébergement, et n'ont pas la bande passante entrant et sortant de leurs propres serveurs pour permettre des milliers de téléchargements simultanés à large bande. Donc, ils louent de l'espace et de la bande passante à un fournisseur de cloud pour fournir le même service.

Désormais, ils ne contrôlent pas ce cloud; c'est un système différent maintenu par une entreprise différente, "ma maison, mes règles". Le fournisseur de logiciels s'inquiète du piratage et de voir sa réputation ternie par un compromis de la société d'hébergement, et pour de bonnes raisons; il s'agit d'une méthode d'attaque courante, et c'est le nom de la société de logiciels sur le logiciel qui a permis à un attaquant d'accéder au réseau d'un utilisateur d'entreprise et de causer des ravages.

La solution consiste pour le producteur du logiciel à hacher les fichiers proposés au téléchargement sur le site d'hébergement, et à les présenter depuis ses propres systèmes sous son contrôle. Maintenant, vous, l'utilisateur final, pouvez télécharger le logiciel à partir du grand site d'hébergement et vérifier que ce que vous avez obtenu correspond à ce que l'éditeur de logiciels a mis en place en allant sur le site de l'éditeur de logiciels et en comparant son hachage de fichier répertorié avec celui à partir duquel vous calculez. le fichier téléchargé. Cela prend beaucoup moins de bande passante pour l'éditeur de logiciels que l'hébergement du fichier réel à télécharger. Maintenant, il n'y a plus un seul point de vulnérabilité; un attaquant doit pirater à la fois le cloud et le site du producteur du logiciel afin de mettre en place un fichier qui passera le hachage. Ils peuvent gâcher les gens qui ne prennent pas la peine de vérifier les hachages (ce qui est beaucoup de gens) en piratant simplement le site d'hébergement et en remplaçant le fichier, ou ils peuvent gâcher les personnes qui vérifient les hachages en piratant le site du fournisseur de logiciels et en modifiant les hachages pour que le hachage du fichier réel ne corresponde plus, mais ils ne peuvent vraiment faire passer pour un fichier piraté que celui de l'éditeur de logiciels en faisant les deux, ce qui est beaucoup plus difficile.

De manière générale, oui - un hachage d'un site http fournit peu ou pas d'assurance que les données proviennent d'une source fiable.

Mais cela dépend de votre définition de la sécurité, c'est-à-dire de votre modèle de menace . L'un des aspects de la sécurité est l'intégrité des données, et vérifier un hachage vous aidera souvent à éviter de perdre du temps sur un mauvais CD-ROM ou un téléchargement corrompu.

Il est préférable d'obtenir un logiciel à partir d'un système de paquets qui fournit une bonne authentification depuis le programmeur, en passant par le contrôle de version, jusqu'à l'empaquetage et la distribution.

Pour votre utilisateur domestique, il est généralement «suffisant» que le fichier soit correct (et par là je veux dire - le téléchargement a fonctionné et il n'y a pas de corruption) - bien que du point de vue de la sécurité, un attaquant puisse tout aussi facilement remplacer le fichier hashes comme les fichiers s'ils le voulaient s'ils sont stockés au même emplacement.

pour un responsable de la sécurité d'entreprise ou pour quelque chose d'un peu plus sensible, vous voudriez vraiment valider le hachage, probablement par un mécanisme hors bande.

Dans la situation que vous avez décrite, la seule utilité d'une signature est simplement de s'assurer que le fichier n'est pas corrompu.

Il existe quelques cas où la vérification du hachage d'un fichier peut s'avérer un avantage de sécurité, même si le hachage n'a pas été téléchargé via une connexion sécurisée:

• Si seulement votre connexion est étant falsifié, vous pouvez visiter la page Web contenant le hachage en utilisant une autre connexion (par exemple un VPN sécurisé). Si la page, lorsqu'elle est visualisée via cette autre connexion, affiche le même hachage, il est beaucoup moins probable qu'elle ait été falsifiée.
  Bien sûr, vous pouvez obtenir le même résultat en téléchargeant le même fichier deux fois via différentes connexions, mais ceci est beaucoup plus rapide.
• Si l'attaquant, humain ou logiciel, ne s'est pas soucié de calculer le hachage du fichier malveillant et de remplacer le hachage d'origine par celui-ci. Attention cependant, se fier au paresseux des attaquants n'est pas la meilleure défense.
• Si le fichier est téléchargé à partir d'un autre site que le hachage et ce site a été compromis mais le site à condition que le hachage ne soit pas . Par exemple, le fichier peut être distribué via un miroir ou un CDN.
• Si le hachage fourni est signé numériquement avec une clé de confiance. Par exemple, les hachages signés avec une signature PGP de confiance.

Néanmoins, lorsque vous fournissez des hachages via une connexion non sécurisée, le principal avantage est que vous pouvez vérifier que le fichier transmis n'a pas été corrompu en transit. De nos jours, cela n'arrive pas très souvent, mais cela se produit. La gravure d'un ISO Linux corrompu peut vous donner une installation corrompue que vous ne remarquerez peut-être que lorsqu'il est déjà trop tard. Flasher votre BIOS avec un téléchargement corrompu pourrait être encore pire.

Une autre chose à considérer est que, bien que fournir des hachages puisse effectivement donner un faux sentiment de sécurité, il est très probable que la personne qui télécharge le fichier l'ont quand même téléchargé, même si aucun hachage n'était présent. Dans ce cas, le petit avantage de sécurité fourni par les hachages peut ne compenser rien du tout.

@Iszi voici une histoire courte ... (ok, peut-être pas "courte" ... désolé pour ça: P)

disons que vous voulez télécharger VLC . Pour les fenêtres. Dernière version (ver. 1.1.5). OK?

Votre premier endroit où aller serait http://www.videolan.org (site officiel ). Mais vous pouvez trouver et obtenir le "même" prog de 5.780.000 sites. N'est-ce pas? (google "vlc download 1.1.5").

Le site officiel indique que MD5 du fichier est "988bc05f43e0790c6c0fd67118821d42" (voir lien). Et vous pouvez obtenir ce prog (ver. 1.1.5) soit sur le serveur WEB officiel de videolan.org ( PAS de HTTPS ). Ou cliquez sur le lien, redirigez vers Sourceforge et obtenez-le. Et encore une fois avec PAS de HTTPS . Mais Sourceforge est un grand nom. Digne de confiance. Droite? Et devine quoi. Votre oncle qui a VLC, vous envoie un lien Rapidshare par e-mail, pour le télécharger. Et votre ami du travail aussi.

Vous le téléchargez donc à partir de ces " sources fiables ".

Amis, sites, versions, oncles. Vous leur faites tous confiance. Droite ? Je ne pense pas. Au moins tu ne devrais pas.

Il existe un (et un seul) moyen de vérifier que ce que vous avez, est le fichier d'origine . Inaltéré, non modifié. Intacte. Et c'est pour comparer le hash de celui-ci. Mais avec quoi? Avec le hachage de la source officielle.

Pas de HTTP (S), pas de signatures numériques, pas de serveur "sécurisé" ou "de confiance". Rien. Vous n'avez besoin d'aucun de ces éléments. L'intégrité des données est votre ami.

C'est la même chose avec PGP / GnuPG. Vous pouvez détecter si un message a été modifié depuis qu'il a été terminé.

@Justice a dit que

Un cracker suffisamment expérimenté peut remplacer le fichier par une version modifiée de manière malveillante et le hash avec celui qui correspond au fichier modifié

Bien sûr, des collisions MD5 ont été trouvées. Et des collisions SHA-1 existent également. Mais pour citer Wikipédia:

Les fonctions de hachage cryptographique généralement utilisées aujourd'hui sont conçues pour être résistantes aux collisions, mais très peu d'entre elles le sont absolument. MD5 et SHA-1 en particulier ont tous deux publié des techniques plus efficaces que la force brute pour trouver des collisions. Cependant, certaines fonctions de compression ont la preuve que trouver une collision est au moins aussi difficile qu'un problème mathématique difficile (comme la factorisation d'entiers ou le logarithme discret). Ces fonctions sont appelées sécurisées de manière prouvée.

Et je ne pense pas qu’un "cracker suffisamment expérimenté" puisse trouver une "mauvaise version" ou créer un fichier / binaire / quel que soit l ' original que vous voulez et faites qu'il ait le même MD5 / SHA-1 que l'original. Et donnez-lui le même aspect (photo). Ou avec la même taille de fichier, ou même le faire fonctionner ou avoir un sens (texte). Pas même proche. Il peut le rendre non détecté pour l'antivirus (s'il est malveillant). C'est une autre histoire. Mais il y a de très mauvais cas de collisions signalés.

Alors, téléchargez à partir de TOUTE (bonne) source que vous aimez, mais comparez le hachage de la source d'origine . Et il y a toujours une source originale .

Si vous y réfléchissiez vraiment, le fait d'avoir plusieurs sites pour héberger votre contenu téléchargeable, ainsi que les clés de hachage, arrêterait la plupart des attaques de remplacement de l'usine. Une fois de plus, l'hypothèse est le modèle de menace dans lequel l'attaquant devrait remplacer in situ plutôt qu'en transit. Même avec une seule source, les copies empêcheraient quiconque de remplacer à la fois le fichier et le hachage.

Et, les sources de fichiers peuvent être corrompues lors du téléchargement.