☰

ファイルをダウンロードするときにチェックサムを比較することが良い習慣なのはなぜですか?

tag-icon • tag-icon tcp
ファイルをダウンロードするときにチェックサムを比較することが良い習慣なのはなぜですか?

ISO ファイルをダウンロード用に提供する Web サイトでは、多くの場合、それらのファイルの md5 チェックサムが提供されており、これを使用して、ファイルが正しくダウンロードされ、破損していないことを確認できます。

なぜこれが必要なのでしょうか? TCP のエラー訂正機能は十分です。パケットが正しく受信されない場合は再送信されます。TCP/IP 接続の本質はデータの整合性を保証するのではないですか?

答え1

他の人が指摘しているように、送信側でチェックサムが計算される前にすでに破損が発生している、MITM がストリーム (データとチェックサム) を傍受して変更している、受信側でチェックサムを検証した後に破損が発生しているなど、トランスポート層のチェックサムでは解決できないデータ破損の可能性は多数あります。

これらすべての可能性を無視して、TCP チェックサムチェックサム自体と、それが実際にデータの整合性を検証する点について考えると、このチェックサムの特性はエラーの検出に関してまったく包括的ではないことがわかります。このチェックサム アルゴリズムが選択された方法は、むしろ、速度に対する要件と時代 (1970 年代後半) の組み合わせを反映しています。

これは、TCP チェックサム計算は次のようになります:

チェックサム: 16 ビット

チェックサム フィールドは、ヘッダーとテキストのすべての 16 ビット ワードの 1 の補数の合計の 16 ビットの 1 の補数です。セグメントにチェックサムの対象となるヘッダーとテキストのオクテットが奇数個含まれている場合、最後のオクテットの右側にゼロが埋め込まれ、チェックサムの目的で 16 ビット ワードが形成されます。この埋め込みはセグメントの一部として送信されません。チェックサムの計算中、チェックサム フィールド自体はゼロに置き換えられます。

つまり、この方法でデータを合計したときにバランスが取れる破損は検出されません。これにより許容されるデータの破損にはさまざまなカテゴリがありますが、単純な例として、16 ビット ワードの順序を変更しても常に検出されません。


実際には、多くの典型的なエラーをキャッチしますが、整合性はまったく保証されません。また、L2 層が整合性チェック (例: イーサネット フレームの CRC32) を実行する方法も役立ちますが、これはローカル リンクでの送信に対してのみであり、破損したデータの多くは TCP スタックに渡されません。

強力なハッシュ、またはできれば暗号署名を使用してデータを検証することは、データの整合性を保証するという点ではまったく異なるレベルです。この 2 つはほとんど比較できません。

答え2

md5sum をチェックする理由はおそらく無数にあるでしょうが、いくつか思い浮かぶのは次の通りです。

  • 悪意のあるアクティビティ - ISO がサーバーから送信される途中で改ざんされた可能性があります
  • ページ自体が偽装されています (md5sum も署名しておくのがベストです :) )
  • ダウンロードが失敗しました（TCPエラー訂正にもかかわらず）（チェックこれ外）
  • ISO が正しく書き込まれなかった

とにかく、ほんの数秒しかかかりません。

答え3

TCP/IP はデータの整合性を保証します*。ただし、ファイルの 100% がダウンロードされたことを保証するものではありません。これが発生する理由は多数考えられます。たとえば、中間のどこかで 1 バイトまたは 2 バイトが欠落している ISO をマウントできる可能性があります。破損している 1 つまたは 2 つの特定のファイルが必要になるまで、問題は発生しません。チェックサムを比較することで、ファイル全体が実際にダウンロードされたことを確認できます。

* コメントを参照

答え4

HTTP 経由でダウンロードされたファイルのチェックサムを検証する理由はいくつかあります。

  • ファイル全体を受け取ったことを確認する
    • 以下のようなクライアントファイアフォックスは、中断された接続を成功したダウンロードとして扱い、切り捨てられたファイルが残るものの、ダウンロードは正常に行われたと主張する場合があります。
  • 正しいファイルを受け取ったことを確認する
    • 例えば、バグのある、侵害された、または悪意のあるサーバーが何か他のものを送信する可能性があります
    • 誰かが転送を改ざんする可能性があります（中間者攻撃） - システムがSuperfishな​​どによって侵害された場合、または使用されている暗号化方法が弱い場合、HTTPSであってもこの攻撃から安全ではありません。
    • また、偽のダウンロード ページが表示される可能性があり、実際のサーバーに接続されていない可能性があります (ただし、この場合、同じ偽のサーバーからチェックサムを取得してもあまり役に立ちません)
    • 多くのISPが、さまざまな理由から、送信中のページにJavascriptを挿入しているのが発見されています1。これがどれだけうまく実装されているかによって、一部のファイルのダウンロードも台無しになる可能性があります。
    • ミラーがファイルの古いバージョンをホストしているか、管理者が間違ったファイルをアップロードした可能性があります。
  • TCPが検出できない何かによってファイルが破損していないことを確認する
    • 例えば、ファイルがサーバー上で破損している可能性があるので、TCPは、すでに破損しているファイルが送信中にさらに破損しないようにすることだけを保証します。
    • または、メモリ/ディスクの故障、ファイルシステムドライバのバグなどにより、到着後に破損している可能性があります。
    • TCPチェックサムは16ビットしかないため、破損したパケットが検出されない可能性はそれほど高くありません（65536分の1）。
  • ISOを使用すると、ディスクが正しく書き込まれたことを確認する

コメントに1つのソースがあります。笑

関連情報