署名のないWebサイトからファイルをハッシュすると、誤った安心感が得られますか？
このことを考慮。ソフトウェアをダウンロードする多くのWebサイトでは、ユーザーがダウンロードしたファイルの整合性を確認できるように、MD5またはSHA1ハッシュも利用できます。ただし、これらのサイトのいくつかは、実際にはWebサイト自体でHTTPS暗号化またはデジタル署名を使用しています。
したがって、事実上認証されていないソースからファイルをダウンロードし、同じソース（または別の認証されていないソース）からのハッシュでそれを検証する場合、ファイルをハッシュすることの実際の値は何ですか？ （デジタル署名がない場合）ユーザーの知らないうちにダウンロードとハッシュの両方が改ざんされた可能性があるため、これは誤った安心感を確立しませんか？
したがって、事実上認証されていないソースからファイルをダウンロードし、同じソース（または別の認証されていないソース）からのハッシュでそれを検証する場合、ファイルをハッシュすることの実際の値は何ですか？
提供されたハッシュを使用すると、ダウンロードしたファイルが転送中に誤って破損していないか、または別のソース（高速ミラー）からダウンロードしたファイルが、このWebサイトでダウンロードできるファイルと同じかどうかを再確認できます。
ただし、追加のセキュリティはそれほど多くありません。十分に熟練したクラッカーは、ファイルを悪意を持って変更されたバージョンに置き換え、ハッシュを変更されたファイルと一致するものに置き換えることができます。または、ネットワークを介して要求をMITMし、要求されたファイルとハッシュの両方を自分で置き換えることができます。
そこの利点は確かに限られています。ご指摘のとおり、サイトの1つを置き換えることができれば、おそらく両方を置き換えることができます。
ただし、これにはいくつかの利点があります。
- これにより、他のサイトが整合性を検証して大きなファイルをホストできるようになります。これで、信頼する理由のないランダムなサードパーティからファイルを取得し、ソースサイト（帯域幅が制限されている可能性がある）に基づいた適切なファイルであることを確認できます。
- サイトの人気が高い場合は、古いハッシュのコピーが十分にあるため、archive.orgやさまざまな検索エンジンのキャッシュなどを介して、一般ユーザーへの侵害をすばやく確認できます。
公開鍵と秘密鍵のペアを使用してファイルに署名することにより、セキュリティが強化されますが、ほとんどのアプリケーションの実際的な利点は、鍵を使用する場合と使用しない場合とで大きく変わりません。キーをWebサイトに投稿し、ハッシュを投稿する代わりにすべてに署名した場合、攻撃者は、ハッシュを置き換えることによって行われたのと同じ効果をキーに置き換えることができます。独立したディストリビューションを持つ本当に大規模なプロジェクトにはこの追加のレイヤーが必要です（Debianが頭に浮かびます）が、それから利益を得る人はほとんどいないと思います。
ハッシュにセキュリティ関連の値を設定するには、次の2つの条件を満たしている必要があります両方。
- ハッシュ値は、整合性を保証するプロトコル（HTTPSなど）を介して配布する必要があります。
- ダウンロードしたファイルは、整合性を保証するプロトコルを介して配布する必要があります。
ファイルもHTTPSで提供される場合、ハッシュは無意味になる傾向があります。SSLは転送中の整合性をすでに保証しています。
ハッシュは、ファイルを変更するのと同じようにハッシュを変更できるため、サーバーを制御する攻撃者から保護することはできません。
例公開されたハッシュの有用性のあるものは、ある日付でファイルをダウンロードし、その後、持っているコピーが正しいことを後で確認したい場合です。ローカルストレージ（たとえば、悪意のある人によって一時的に盗まれた可能性のあるUSBキー上にあった）。 別の例は、ダウンロード自体がp2pネットワークから行われた場合です。これは、そのようなものがバルクソフトウェアを多くのクライアント（これがBlizzard Downloaderが行うことです）：p2pを使用してファイルを取得してから、メインのHTTPSサイトから小さなハッシュ値を取得します。 番目の例（私が専門的に遭遇する）は、厳しい監査条件下で信頼されたシステムを構築する場合（たとえば、新しいルートCAを作成する場合）：使用するソフトウェアが本物であることを監査者が確認できるようにしたい。ハッシュファイルが（HTTPS経由で）配布されている場合、監査人はローカルアーカイブに対してそれをチェックするだけです。そうでなければ、監査人はダウンロード全体を目撃する必要があります。監査人の時給を考えると、ハッシュが望ましい。
ハッシュを安全に配布する必要があるため、生のハッシュを保持するだけではメリットが限定的であり、ほとんどの人はハッシュを適切にチェックする方法や多くの考えられる問題に対処する方法を知りません。
優れたセキュリティを確保するための正しい方法は、公開鍵技術を使用してハッシュに署名し、それをソフトウェア配布スキーム全体にシームレスに統合することです。公開鍵を安全に配布することは依然として必要ですが、これは1回行うことができます。オペレーティングシステムのインストール時。私はそれが本質的にWindowsとMacOSでOSの更新とOfficeのようないくつかの主要なパッケージで行われていることだと思います。
何よりも、必要なソフトウェアのほぼすべてが同じ標準キーでカバーされている場合に最適です。これは基本的に、Debian、Ubuntu、Red Hat、Suseなどのほとんどのオープンソースソフトウェアディストリビューションで発生します。これらは、文字通り数万のパッケージを安全に配布し、すべてが配布の一部として管理されるキーで自動的に署名されます。安全性が高い。そして、それはほとんど誰でも手動チェックを行う必要なしに起こります。
したがって、事実上認証されていないソースからファイルをダウンロードし、同じソース（または別の認証されていないソース）からのハッシュでそれを検証する場合、ファイルをハッシュすることの実際の値は何ですか？
この状況では、ハッシュがファイルへのリンクのすぐ横にある場合、その値は主に、ファイルが転送中に損傷または破損していないことを確認することです。
セキュリティの観点からは、あなたの言う通りです。これは、ファイルが改ざんされていないことを証明する価値はほとんどありません。ハッキングされたファイルにアクセスしてアップロードした（またはハッキングしたコピーを指すようにリンクを変更した）可能性のあるユーザーは、その横にあるハッシュを置き換えることもできるためです。そのため、セキュリティが目的の場合、この方法はほとんど行われません。
通常、ハッシュダイジェストが提供される場合、それはソフトウェアプロデューサーから直接提供されます。彼らはダウンロード用のソフトウェアを提供していますが、独自のサーバーでソフトウェアを直接ホストすることに消極的です。彼らはホスティング会社ではなくソフトウェア会社であり、数千の同時ブロードバンドダウンロードを可能にする独自のサーバーの内外に帯域幅がありません。したがって、彼らは同じサービスを提供するためにクラウドプロバイダーからスペースと帯域幅を借ります。
現在、彼らはこのクラウドを制御していません。それは別の会社によって維持されている別のシステム、「私の家、私のルール」です。ソフトウェアプロバイダーは、ホスティング会社の侵害によってハッキングが行われ、その良い名前が損なわれることを心配しています。これは一般的な攻撃方法であり、攻撃者が企業ユーザーのネットワークに侵入して大混乱を引き起こすことを可能にしたソフトウェア上のソフトウェア会社の名前です。
ソリューションは、ソフトウェアプロデューサーがホスティングサイトでダウンロード用に提供されているファイルをハッシュし、そのハッシュをその管理下にある独自のシステムから提示することです。これで、エンドユーザーは大きなホスティングサイトからソフトウェアをダウンロードし、ソフトウェア会社のサイトにアクセスして、リストされたファイルハッシュを計算元のファイルハッシュと比較することにより、取得したものがソフトウェア会社が提供したものであることを確認できます。ダウンロードしたファイル。これにより、ソフトウェア会社がダウンロードする実際のファイルをホストするよりもはるかに少ない帯域幅で済みます。現在、脆弱性の単一点はもうありません。攻撃者は、ハッシュチェックを通過するファイルを配置するために、ソフトウェアプロデューサーのサイトとの両方をハッキングする必要があります。彼らは、ホスティングサイトをハッキングしてファイルを置き換えるだけで、ハッシュをチェックする手間をかけない人（多くの人です）を台無しにしたり、した人を台無しにしたりできますソフトウェアプロバイダーのサイトをハッキングしてハッシュを確認し、実際のファイルのハッシュが一致しないようにハッシュを変更しますが、ハッキングされたファイルをソフトウェア会社のファイルとして偽装するには、両方を実行する必要があります。はるかに難しい。
一般的に言って、はい-httpサイトからのハッシュは、データが信頼できるソースからのものであることをほとんどまたはまったく保証しません。
ただし、セキュリティの定義、つまり脅威モデルによって異なります。セキュリティの1つの側面はデータの整合性です。ハッシュをチェックすると、多くの場合、不良なCDROMや破損したダウンロードで時間を無駄にすることを回避できます。
プログラマーからバージョン管理を介してパッケージングおよび配布まで、優れた認証を提供するパッケージシステムからソフトウェアを取得する方がはるかに優れています。
ホームユーザーにとって、ファイルが正しいことは通常「十分」快適です（つまり、ダウンロードは機能し、破損はありません）。ただし、セキュリティの観点から、攻撃者はファイルハッシュを同じ場所に保存されている場合は、必要に応じてファイルを作成します。
企業のセキュリティ担当者や少し機密性の高いものについては、おそらく帯域外メカニズムによって、ハッシュを本当に検証する必要があります。
あなたが説明した状況では、署名の唯一の用途は、ファイルが破損していないことを確認することです。
安全な接続を介してハッシュがダウンロードされなかったとしても、ファイルのハッシュをチェックすることがセキュリティ上の利点を証明することができるいくつかのケースがあります：
- 接続のみが改ざんされている場合は、別の接続（安全なVPNなど）を使用してハッシュを含むWebページにアクセスできます。ページが他の接続を介して表示されたときに同じハッシュが表示される場合、改ざんされている可能性ははるかに低くなります。
もちろん、異なる接続を介して同じファイルを2回ダウンロードすることで同じ結果を得ることができますが、これははるかに高速です。 - 攻撃者が人間であろうとソフトウェアであろうと、悪意のあるファイルのハッシュを計算して元のハッシュをそのファイルで置き換えることを気にしなかった場合。ただし、攻撃者が怠惰であることに依存することは最善の防御ではありません。
- ファイルがハッシュとは異なるサイトからダウンロードされ、そのサイトが危険にさらされているが、ハッシュを提供しているサイトがでなかった場合。たとえば、ファイルは mirror または [〜＃〜] cdn [〜＃〜] を介して配布できます。
- 提供されたハッシュが信頼できる鍵でデジタル署名されている場合。たとえば、信頼できるPGP署名で署名されたハッシュ。
それでも、保護されていない接続を介してハッシュを提供する場合の主な利点は、転送されたファイルが転送中に破損していないことを確認できることです。今日、これはそれほど頻繁には発生しませんが、発生します。破損したLinux ISOを書き込むと、インストールが破損する可能性があり、インストールがすでに手遅れである場合にのみ気付く場合があります。ダウンロードが破損しているBIOSをフラッシュすると、さらに悪くなる可能性があります。
考慮すべきもう1つのことは、ハッシュを提供すると確かに誤った安心感を与える可能性がある一方で、たとえハッシュが存在しなかったとしても、ファイルをダウンロードした人がとにかくそれをダウンロードしていた可能性が非常に高いということです。その場合、ハッシュによって提供される小さなセキュリティ上の利点は、何にも勝らないかもしれません。
あなたがそれについて本当に考えた場合、ダウンロード可能なコンテンツをホストする複数のサイトをハッシュキーと一緒に持つことで、ミル交換攻撃のほとんどの実行を止めることができます。ここでも、攻撃者が移動中ではなく現場で交換する必要がある脅威モデルが想定されています。ソースが1つであっても、コピーにより、誰もがファイルとハッシュの両方を置き換えることができなくなります。
また、ファイルソースはダウンロードによって破損する可能性があります。
@Isziここに短い話があります...（わかりました、「短い」ではないかもしれません...すみません：P）
あなたがダウンロードしたい[〜＃〜] vlc [〜＃〜]。窓用。最新バージョン（バージョン1.1.5）。 Ok？
最初に行く場所は http://www.videolan.org （officialsite）です。しかし、5.780.000サイトから「同じ」PROGを見つけて取得できます。 正しいですか？（google "vlc download 1.1.5"）.
officialサイトによると、ファイルのMD5 は「988bc05f43e0790c6c0fd67118821d42」です（リンクを参照）。そして、あなたは公式の videolan.org WEBサーバー （NO HTTPS）からこのprog（ver。1.1.5）を取得できます。 。または、リンクをクリックし、Sourceforgeにリダイレクトして取得します。そして再びNO HTTPSを使用します。しかし、Sourceforgeはbigの名前です。信頼できる。正しい？そして、何を推測します。 VLCを持っているあなたの叔父は、それをダウンロードするために電子メールでRapidshareリンクを送ります。そして、あなたの友人も仕事からです。
したがって、これらの「信頼できるソース」からダウンロードします。
友達、サイト、バージョン、おじ。あなたはそれらすべてを信頼しています。正しい ？そうは思いません。少なくともあなたはすべきではない。
取得したものを確認する方法は1つだけですは元のファイルです。変更なし、変更なし。手つかず。そして、それはそれのハッシュを比較することです。しかし、何で？ 公式ソースからのハッシュを使用します。
HTTP（S）、デジタル署名、「セキュア」または「信頼された」サーバーはありません。何もない。これらは必要ありません。データの整合性はあなたの友人です。
PGP/GnuPGでも同じです。完了後にメッセージが変更されたかどうかを検出できます。
@正義は言った
十分に熟練したクラッカーは、ファイルを悪意を持って変更されたバージョンに置き換え、ハッシュを変更されたファイルに一致するものに置き換えることができます
確かに、MD5衝突が存在することがわかりました。そして SHA-1衝突 も存在します。しかし引用する Wikipedia ：
今日一般的に使用されている暗号化ハッシュ関数は 衝突耐性 となるように設計されていますが、完全にそうであるものはごくわずかです。特にMD5とSHA-1は、衝突を検出するためのブルートフォースよりも効率的な手法を公開しています。ただし、一部の圧縮関数には、衝突を見つけることが少なくともいくつかの難しい数学的問題（整数因数分解や離散対数など）と同じくらい難しいという証拠があります。これらの関数は おそらく安全 と呼ばれます。
そして、「十分に熟練したクラッカー」が「悪いバージョン」を見つけたり、元のあなたの1つのファイル/バイナリ/何でも作ることができるとは思わない欲しいとmakeそれはsameMD5/SHA-1を元の。そして、それを同じように見せます（pic）。または、同じファイルサイズで実行したり、実行したり意味をなしたりすることもできます（テキスト）。程遠い。 （悪意のある場合は）ウイルス対策で検出されないようにすることができます。それは別の話です。しかし 衝突のいくつかの本当に悪いケース が報告されています。
だから、好きなところからダウンロードしてくださいsourceが、元のソースからハッシュを比較してください。そして、常に1つの元のソースがあります。