Po co obliczać sumy kontrolne pobranych plików?

Często widzę sumę kontrolną podaną obok pliku dostępnego do pobrania. Cel tej praktyki umyka mi. Oczywiste jest wykrywanie uszkodzonych plików, ale co może być przyczyną tego uszkodzenia i czy w ogóle jest prawdopodobne?

Z pewnością plik nie zostanie uszkodzony przez błędy transmisji, ponieważ są one wykrywane przez protokół sieciowy. I z pewnością każdy atakujący, który mógłby zmienić plik w złośliwych celach, może również zmienić podaną sumę kontrolną. Czy sprawdzamy błędy dysku twardego? Czy są one bardziej prawdopodobne podczas pisania niż podczas czytania? Czy brakuje mi czegoś ważnego?

Wykrywanie korupcji nie jest całkowicie poprawne. Ustalenie integralności oprogramowania byłoby bardziej poprawnym użyciem. Zwykle oprogramowanie nie jest dystrybuowane z jednego serwera. To samo oprogramowanie może być dystrybuowane z wielu serwerów. Kiedy więc pobierasz określone oprogramowanie, jako źródło pobierania wybierany jest serwer najbliżej miejsca docelowego, aby zwiększyć prędkość pobierania. Jednak nie zawsze można ufać tym „nieoficjalnym” serwerom (stronom trzecim). Mogą / mogą zawierać trojany / wirusy / adware / backdoory w programie, co nie jest dobre .

Aby więc upewnić się, że pobrane oprogramowanie jest dokładnie takie samo jak oprogramowanie „oficjalne” wydane przez daną organizację, używana jest suma kontrolna. Algorytmy używane do generowania sum kontrolnych są takie, że nawet niewielka zmiana w programie skutkuje zupełnie inną sumą kontrolną.

Przykład zaczerpnięty z Practical Unix i Internet Security

MD5 (w niebieskim polu jest 1500 $) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (w niebieskim polu jest 1100 $) = d6dee11aae89661a45eb9d21e30d34cb

Wiadomości, które różnią się tylko jednym znakiem (i w obrębie tego znaku tylko jednym bitem binarnym), mają zupełnie inne skróty wiadomości.

Jeśli pobrany plik ma taką samą sumę kontrolną jak suma kontrolna podana na „oficjalnej” stronie internetowej, można założyć, że oprogramowanie nie jest modyfikowane.

Uwaga dodatkowa: Teoretycznie dwa różne pliki MOGĄ mieć tę samą wartość skrótu. Aby algorytm skrótu / sumy kontrolnej mógł zostać uznany za bezpieczny, znalezienie innego pliku, który generuje tę samą sumę kontrolną, powinno być bardzo drogie obliczeniowo.

I z pewnością każdy atakujący, który mógłby zmienić plik w złośliwych celach, może również zmienić podaną sumę kontrolną.

Nie zawsze.

Możesz mieć link do treści wraz z sumą kontrolną wyświetlaną na HTTPS. Łącze może być nieszyfrowanym łączem - zwykłym HTTP lub FTP, lub czymś innym.

Z drugiej strony, niezaszyfrowane połączenie może łatwo zostać obsadzone przez środkową załogę, z drugiej strony może być szybsze lub wygodniejsze dla webmastera (potrzeba mniej zasobów obliczeniowych i umożliwia sieci buforowanie tego typu danych).

Jeśli suma kontrolna jest podawana w nieprzerwanym zaufanym połączeniu, a ładunek odpowiada sumie kontrolnej, otrzymujesz to, co najlepsze z obu światów (pod warunkiem, że suma kontrolna jest kryptograficznie bezpieczna).

To powiedziawszy, przypomniałeś mi, że istnieją dystrybucje, które twierdzą, że są „bezpieczne”, a jednak ich strona internetowa jest dostępna tylko przez HTTP, podobnie jak linki do ich obrazów.

Przykłady:

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

To trochę zabawne, ponieważ nie możesz być bardziej niepewny. Nawet jeśli sami nie są złośliwi, każdy dostawca usług internetowych może łatwo zastąpić zarówno stronę internetową, jak i obraz fałszywkami, a nakłonienie kogoś do zainstalowania sfałszowanego systemu operacyjnego, sprawiając wrażenie, jakby dostał „bezpieczną” dystrybucję Linuksa, jest ostatecznym pwnage.

O ile sprawdzanie błędów TCP / IP nie łapie wszystkiego: od /programming//a/17083365/2551539

Mogą wystąpić różne błędy (które wykryje TCP) [wskazał Jacob Krall] :

• Niepoprawna kolejność pakietów
• Utrata pakietów
• Uszkodzone dane w pakiecie
• Pakiety fantomowe (odbiorca dostaje pakiety, które nigdy nie zostały wysłane)

Edytuj z dodatkowymi informacjami:

Strona 9 tego badania: http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf sugeruje, że istnieją błędy, które mogą zostać wykryte przez TCP. Rozumiem, że dzieje się tak, gdy błędny datagram (zwany w badaniu „złym bliźniakiem”) ma taką samą sumę kontrolną jak datagram zamierzony (w badaniu nazywany „dobrym bliźniakiem”).

Mogą wystąpić błędy transmisji. Protokoły warstwy łącza zwykle zawierają sumy kontrolne lub kody korygujące błędy, aby ich uniknąć, ale nie są idealne: istnieje niewielka szansa, że ​​błąd nie zostanie naprawiony. Pakiety TCP zawierają również sumę kontrolną, co zmniejsza prawdopodobieństwo błędów o 2 ^ 16. To powoduje bardzo małe, ale niezerowe prawdopodobieństwo błędu transmisji. Jest to coś, z czym większość ludzi nigdy nieświadomie się nie spotka w ciągu swojego życia, ale nie ma ona zasięgu wiarygodności kryptograficznych sum kontrolnych nigdy za miliard lat.

Błąd sprzętowy na kliencie, taki jak uszkodzenie dysku, prawdopodobnie nie zostanie wykryty poprzez sprawdzenie zaraz po pobraniu, ponieważ suma kontrolna zostanie obliczona na podstawie kopii z pamięci podręcznej. Z drugiej strony sprawdzanie nośników rozruchowych pod kątem uszkodzeń, jeśli nie udało się ich uruchomić, jest naprawdę przydatne - naprawdę testujesz nośnik i masz założenie, że sprzęt może być zły.

Prawdziwym powodem do obliczenia sum kontrolnych jest w rzeczywistości wykrycie błędów na poziomie oprogramowania. Tak się dzieje. Możliwe błędy to:

• Plik został częściowo pobrany. Serwery i przeglądarki internetowe zwykle źle sprawdzają się w wykrywaniu przerwanych połączeń i usuwaniu częściowych plików. Błąd może występować podczas pobierania lub mógł być podczas przesyłania, sumuje się.
• Po drodze było trochę korupcji. Na przykład niektóre węzły pośrednie w dystrybucji pliku zdecydowały się zastosować konwersję kodowania tekstu do pliku binarnego. Lub źle skonfigurowany serwer wyświetlał komunikat o błędzie zamiast zawartości.
• Wariant: przesłano niewłaściwy plik.
• Rzadko, ale może być przydatny do ochrony: przeciwnik zmienił plik, ale nie był w stanie zmienić referencyjnej sumy kontrolnej. Infrastruktury bezpieczeństwa zwykle utrudniają atakującemu propagowanie nieprawidłowej sumy kontrolnej niż nieprawidłowego pliku. Na przykład duże pliki są często dystrybuowane przez kopie lustrzane, podczas gdy sumy kontrolne są obsługiwane przez centralną witrynę o mniejszych możliwościach manipulacji (dostęp do serwera tylko dla liderów projektów, dystrybucja przez HTTPS).

W praktyce sprawdzenie rozmiaru pobranego pliku wykrywa najczęściej występujące błędy, które są okrojone lub nieprawidłowo przekonwertowane. Zaletą sum kontrolnych jest to, że wykrywają znacznie więcej problemów.

Teoretycznie sieć prawidłowo dostarczałaby każdy segment i byłyby odpowiednio zmontowane na dysku i nic nie byłoby nie tak.

W rzeczywistości komputery to maszyny i oprogramowanie, które zostały zaprojektowane i zbudowane przez omylnych ludzi. W przypadku, gdy pobieranie z jakiegoś powodu nie powiedzie się poprawnie, na przykład pobieranie przez jakieś urządzenie pośredniczące, czy to nieszkodliwe, czy nikczemne, które zniekształca dane, dobrze jest sprawdzić, czy plik prawie na pewno był pobrane jako dokładna replika pliku po stronie dostawcy.

Wysokiej jakości suma kontrolna jest niezawodną metodą sprawdzania integralności danych.

Żadna suma kontrolna nie może być w 100% niezawodna, ponieważ wiele plików jest mapowanych na tę samą sumę kontrolną.

Kiedy dodać kolejną kontrolną do pociągu my wielowarstwowego prawdopodobieństwo wykrycia błędu.

W Internecie jest tak duży ruch, że błędy są w rzeczywistości dość powszechne.

Suma kontrolna pomoże również zapobiec uszkodzeniu pobierania z powodu następującej sytuacji:

Serwer ma błąd wewnętrzny podczas udostępniania pobierania, dlatego pobieranie zostało zakończone.

Kiedy tak się dzieje, istnieje kilka możliwych rezultatów:

• Dobry serwer - wdrożenie serwera z kodowaniem transferu pakietowego jest nie buggy:
  • Dobry klient (jak cURL, wget) będzie w stanie poinformować cię, że jest to złe pobieranie, ponieważ końcowa porcja nigdy nie została wysłana z serwera.
  • Zły klient pomyśli, że pobieranie zostało zakończone, ponieważ z serwera nie otrzymano żadnych danych.
• Bad serwer - wdrożenie serwera z kodowaniem transferu pakietowego jest wadliwy, że wysyła kawałek obciążeniowy dla tej złej pobrania:
  • Każdy klient pomyśli, że pobieranie zakończyło się pomyślnie.

Widziałem te zachowania wśród popularnych narzędzi klienckich i struktur serwerowych, więc jeśli nie używasz sumy kontrolnej, to w przypadku „dobrego serwera + złego klienta” lub „złego serwera + dowolnego klienta”, uszkodzone pobieranie zostanie niezauważone .