Websites, die ISO-Dateien zum Download bereitstellen, geben häufig die MD5-Prüfsummen dieser Dateien an, mit denen wir bestätigen können, dass die Datei korrekt heruntergeladen wurde und nicht beschädigt ist.
Warum ist das notwendig? Sicherlich reichen die Fehlerkorrektureigenschaften von TCP aus. Wenn ein Paket nicht korrekt empfangen wird, wird es erneut gesendet. Garantiert nicht die Natur einer TCP/IP-Verbindung die Datenintegrität?
Antwort1
Wie bereits von anderen angemerkt, gibt es zahlreiche Möglichkeiten zur Datenbeschädigung, bei denen keine Prüfsumme auf der Transportebene helfen kann. Dazu gehören beispielsweise eine Beschädigung, die bereits vor der Berechnung der Prüfsumme auf der Sendeseite auftritt, ein MITM, das den Stream (sowohl Daten als auch Prüfsummen) abfängt und ändert, eine Beschädigung, die nach der Validierung der Prüfsumme auf der Empfangsseite auftritt usw.
Wenn wir alle diese anderen Möglichkeiten außer Acht lassen und uns auf die Besonderheiten desTCP-Prüfsummeselbst und was es tatsächlich in Bezug auf die Validierung der Datenintegrität tut, stellt sich heraus, dass die Eigenschaften dieser Prüfsumme im Hinblick auf die Erkennung von Fehlern überhaupt nicht umfassend sind. Die Art und Weise, wie dieser Prüfsummenalgorithmus gewählt wurde, spiegelt eher die Geschwindigkeitsanforderung in Kombination mit dem Zeitrahmen (Ende der 1970er Jahre) wider.
So funktioniert dasTCP-Prüfsummeist berechnet:
Prüfsumme: 16 Bit
Das Prüfsummenfeld ist das 16-Bit-Komplement der Summe aller 16-Bit-Wörter im Header und Text. Wenn ein Segment eine ungerade Anzahl von Header- und Textoktetten enthält, deren Prüfsumme berechnet werden soll, wird das letzte Oktett rechts mit Nullen aufgefüllt, um ein 16-Bit-Wort für Prüfsummenzwecke zu bilden. Das Auffüllfeld wird nicht als Teil des Segments übertragen. Beim Berechnen der Prüfsumme wird das Prüfsummenfeld selbst durch Nullen ersetzt.
Dies bedeutet, dass jede Beschädigung, die sich bei der Summierung der Daten auf diese Weise ausgleicht, unentdeckt bleibt. Dies ermöglicht eine Reihe von Kategorien von Datenbeschädigungen, aber nur ein triviales Beispiel: Das Ändern der Reihenfolge der 16-Bit-Wörter wird immer unentdeckt bleiben.
In der Praxis werden viele typische Fehler erkannt, aber die Integrität wird nicht garantiert. Hilfreich ist auch, dass die L2-Schicht ebenfalls Integritätsprüfungen durchführt (z. B. CRC32 von Ethernet-Frames), allerdings nur für die Übertragung über die lokale Verbindung, und viele Fälle beschädigter Daten werden nicht einmal an den TCP-Stack weitergeleitet.
Die Validierung der Daten mithilfe eines starken Hashs oder besser noch einer kryptografischen Signatur liegt hinsichtlich der Gewährleistung der Datenintegrität auf einer ganz anderen Ebene. Die beiden sind kaum miteinander vergleichbar.
Antwort2
Es gibt wahrscheinlich zig Gründe, warum man die MD5-Summe überprüfen sollte, aber mir fallen ein paar ein:
- Böswillige Aktivitäten - Ihr ISO könnte auf dem Weg vom Server manipuliert worden sein
- Die Seite selbst ist gefälscht (am besten ist es, wenn auch die MD5-Summen signiert sind :))
- Abgebrochener Download (trotz TCP-Fehlerkorrektur) (prüfen SieDasaus)
- ISO falsch gebrannt
Und es dauert sowieso nur ein paar Sekunden.
Antwort3
TCP/IP garantiert zwar die Datenintegrität*, garantiert jedoch nicht, dass eine Datei zu 100 % heruntergeladen wurde. Dafür kann es viele Gründe geben. Beispiel: Es ist möglich, dass Sie ein ISO mounten, dem irgendwo in der Mitte ein oder zwei Bytes fehlen. Sie werden damit kein Problem haben, bis Sie ein oder zwei bestimmte Dateien benötigen, die beschädigt sind. Durch den Vergleich der Prüfsummen wird sichergestellt, dass Sie wirklich die gesamte Datei heruntergeladen haben.
* siehe Kommentar
Antwort4
Es gibt mehrere Gründe, die Prüfsumme einer per HTTP heruntergeladenen Datei zu überprüfen:
- Sicherstellen, dass Sie die gesamte Datei erhalten haben
- Einige Kunden, wie beispielsweiseFeuerfuchs, kann eine unterbrochene Verbindung als erfolgreichen Download behandeln und Ihnen eine abgeschnittene Datei hinterlassen, aber behaupten, dass der Download erfolgreich war
- Sicherstellen, dass Sie die richtige Datei erhalten haben
- Beispielsweise könnte ein fehlerhafter, kompromittierter oder bösartiger Server Ihnen etwas anderes senden
- jemand könnte die Übertragung manipulieren (Man-in-the-Middle-Angriff) - selbst HTTPS ist davor nicht sicher, wenn Ihr System beispielsweise durch Superfish kompromittiert wurde oder die verwendete Verschlüsselungsmethode schwach ist
- Sie könnten Ihnen auch nur eine falsche Download-Seite präsentieren, sodass Sie nicht einmal mit dem echten Server verbunden sind (in diesem Fall helfen die Prüfsummen allerdings nicht viel, wenn Sie sie vom gleichen gefälschten Server erhalten).
- Eine Reihe von ISPs wurde dabei erwischt, wie sie aus verschiedenen Gründen Javascript in Seiten während der Übertragung einfügten. 1 Je nachdem, wie gut dies umgesetzt wird, könnte es auch einige Dateidownloads beeinträchtigen.
- Ein Spiegelserver könnte eine veraltete Version der Datei hosten oder der Administrator könnte die falsche Datei hochgeladen haben.
- Sicherstellen, dass die Datei nicht durch etwas beschädigt wurde, das TCP nicht erkennen kann
- Beispielsweise könnte die Datei auf dem Server beschädigt sein. TCP stellt dann lediglich sicher, dass die bereits beschädigte Datei bei der Übertragung nicht noch weiter beschädigt wurde.
- oder es könnte nach der Ankunft bei Ihnen beschädigt werden, durch fehlerhaften Speicher/Festplatte, fehlerhaften Dateisystemtreiber usw.
- TCP-Prüfsummen sind nur 16-Bit, daher ist die Wahrscheinlichkeit, dass ein beschädigtes Paket nicht erkannt wird, nicht astronomisch (1 zu 65536).
- Mit einer ISO-Datei sicherstellen, dass die Disc richtig gebrannt wurde
1 Quellen im Kommentar, weil lol rep