Perché è buona norma confrontare i checksum quando si scarica un file?

16

I siti Web che forniscono file ISO per il download spesso forniscono i checksum md5 di quei file, che possiamo usare per confermare che il file è stato scaricato correttamente e che non è stato danneggiato.

Perché è necessario? Sicuramente l'errore di correzione delle proprietà di TCP sono sufficienti. Se un pacchetto non viene ricevuto correttamente, verrà ritrasmesso. La natura stessa di una connessione TCP / IP non garantisce l'integrità dei dati?

tcp

— Aditya K
fonte

10

Inoltre, non dimenticare i possibili bug nel software e nell'hardware durante il trasferimento dei dati, anche negli endpoint.

— sebix,

Il download potrebbe essere terminato in anticipo di pochi byte. Non lo noterai necessariamente in base alle dimensioni del file se non stai prestando attenzione e la correzione dell'errore TCP avrebbe verificato solo la parte dei dati effettivamente arrivati.

— Kevin Keane,

Checksums può essere utile ma, in 20 anni di lavoro con i computer, non ricordo di averlo usato una volta.

— Pedro Lobito,

2

MD5 sono hash, non checksum. Un checksum viene utilizzato per verificare la presenza di errori, in particolare errori di bit durante la trasmissione. Un hash crittografico ha lo scopo di garantire che i dati siano esattamente gli stessi. In tal senso, un hash sarebbe un superset di checksum, ma non sono gli stessi. A parte questo MD5 è rotto da 10 anni (vedi l' articolo di Wikipedia, sezione Sicurezza ).

— 0xC0000022L

20

Come è stato notato da altri, ci sono molte possibilità di corruzione dei dati in cui qualsiasi checksum a livello di trasporto non può aiutare, come la corruzione che si verifica già prima che il checksum sia calcolato sul lato di invio, un MITM che intercetta e modifica il flusso (anche i dati come checksum), corruzione che si verifica dopo la convalida del checksum alla fine della ricezione, ecc.

Se ignoriamo tutte queste altre possibilità e ci concentriamo sulle specifiche del checksum TCP stesso e su ciò che effettivamente fa in termini di convalida dell'integrità dei dati, si scopre che le proprietà di questo checksum non sono affatto complete in termini di rilevamento degli errori. Il modo in cui è stato scelto questo algoritmo di checksum riflette piuttosto il requisito della velocità in combinazione con il periodo di tempo (fine anni '70).

Ecco come viene calcolato il checksum TCP :

Checksum: 16 bit

Il campo di checksum è il complemento a 16 bit della somma del complemento a uno di tutte le parole a 16 bit nell'intestazione e nel testo. Se un segmento contiene un numero dispari di ottetti di intestazione e di testo da sommare, l'ultimo ottetto viene riempito a destra con zeri per formare una parola di 16 bit ai fini del checksum. Il pad non viene trasmesso come parte del segmento. Durante il calcolo del checksum, il campo del checksum stesso viene sostituito con zeri.

Ciò significa che qualsiasi corruzione che si equilibra quando si sommano i dati in questo modo non verrà rilevata. Ci sono una serie di categorie di corruzione nei dati che questo consentirà, ma solo come un esempio banale: cambiare l'ordine delle parole a 16 bit rimarrà sempre inosservato.

In pratica, rileva molti errori tipici ma non garantisce affatto l' integrità. È anche aiutato dal modo in cui il livello L2 esegue anche i controlli di integrità (ad esempio CRC32 dei frame Ethernet), anche se solo per la trasmissione sul collegamento locale, e molti casi di dati danneggiati non vengono nemmeno passati allo stack TCP.

Convalidare i dati usando un hash forte, o preferibilmente una firma crittografica, è su un livello completamente diverso in termini di garantire l'integrità dei dati. I due non possono nemmeno essere paragonati.

— Håkan Lindqvist
fonte

Migliore risposta! Odio come le altre risposte confondano i concetti di hash e checksum crittografici.

— 0xC0000022L

20

Probabilmente ci sono milioni di ragioni per cui si dovrebbe controllare md5sum, ma alcuni mi vengono in mente:

Attività dannosa: la tua ISO potrebbe essere stata manomessa durante il percorso dal server
La pagina stessa è falsificata (è meglio avere anche md5sums firmato :))
Download interrotto (nonostante la correzione dell'errore TCP) (controlla questo )
ISO bruciato in modo errato

E ci vogliono solo pochi secondi.

— Konrad Gajewski
fonte

21

Significa anche che è abbastanza sicuro scaricare un ISO da un sito mirror casuale, a condizione che si ottengano i checksum da qualche parte di fiducia; ad esempio un post firmato PGP nella mailing list di foo-annuncio.

— richardb,

2

In realtà non ha nulla a che fare con la protezione da attività dannose. Se l'ISO avrebbe potuto essere sostituito con uno malevolo, lo stesso potrebbe valere il valore di checksum MD5. Farli firmare è una questione diversa, ma non è ciò che l'OP chiede. Quindi, invece di "attività malevole" essere la prima nella tua lista (suona bene), in realtà non dovrebbe nemmeno essere nella tua lista. Stai dando alla gente un falso senso di sicurezza, che è pericoloso. superuser.com/questions/849845/…

— Austin '' Danger ''

1

@ Austin''Pericolo''Power Umm, no, Konrad ha ragione. Per uno, il mirror di download di solito è diverso dal sito che mostra il checksum e, in secondo luogo, ci sono molti ISP al mondo che manipolano il traffico: i checksum TCP andranno bene, ma stai scaricando un altro file. E, naturalmente, manca anche un altro punto: il file potrebbe essere stato danneggiato sul server dopo la creazione del checksum. Succede tutto il tempo, specialmente per i server più "hobbisti" (senza impostazioni RAID appropriate ecc.).

— Luaan,

2

Una risposta a partire dal 2015 dovrebbe consigliare contro hash MD5 . Tale algoritmo è stato rotto negli ultimi dieci anni (nessuna esagerazione!). Inoltre, stai mescolando checksum e hash. Sono due cose diverse con intenzioni diverse dietro di loro.

— 0xC0000022L

1

Aggiungere per aggiungere al commento di @ 0xC0000022L SHA1 è meglio evitare se la sicurezza è già una delle maggiori preoccupazioni, sebbene sia essa che MD5 siano perfettamente adeguate a difendersi dalla corruzione accidentale.

— David Spillett,

6

TCP / IP garantisce l'integrità dei dati *. Ma non garantisce che il 100% di un file sia stato scaricato. Ci possono essere molte ragioni per cui ciò potrebbe accadere. Ad esempio: è possibile montare un ISO che manchi uno o due byte da qualche parte nel mezzo. Non avrai problemi con esso fino a quando non avrai bisogno di uno o due file particolari che sono corrotti. Il confronto dei checksum garantisce che tu abbia davvero scaricato l'intero file.

* vedi commento

— Daniel
fonte

8

Penso che "garantisca l'integrità dei dati" sia davvero un eccesso di vendite di ciò che effettivamente fa. Fa un tentativo di verificare l'integrità dei dati con un approccio molto snello, che non è particolarmente forte.

— Håkan Lindqvist,

6

Il checksum TCP ha solo 16 bit. Ciò significa che, in assenza di altri checksum, uno su ogni 65536 pacchetti danneggiati verrà accettato come non corrotto. Se, ad esempio, stavi scaricando un'immagine DVD da 8 GB su un collegamento rumoroso con un tasso di corruzione dell'1%, ti aspetteresti 81 pacchetti non corretti.

MD5 è un checksum molto più grande, a 128 bit. Le probabilità di quei 81 pacchetti che producono qualcosa con lo stesso checksum dell'originale sono circa 1 su 1.000.000.000.000.000.000.000.000.000.000.000.000.

— marchio
fonte

6

Esistono diversi motivi per verificare il checksum di un file scaricato tramite HTTP:

Assicurarsi di aver ricevuto l'intero file
- Alcuni client, come Firefox , potrebbero considerare una connessione interrotta come un download riuscito, lasciandoti un file troncato ma dichiarandolo scaricato OK
Assicurarsi di aver ricevuto il file corretto
- ad esempio un server difettoso, compromesso o dannoso potrebbe inviarti qualcos'altro
- qualcuno potrebbe manomettere il trasferimento (attacco man-in-the-middle) - anche HTTPS non è al sicuro da questo se il tuo sistema è compromesso da Superfish, o se il metodo di crittografia utilizzato è debole
- Potrebbero anche presentarti una pagina di download falsa, quindi non sei nemmeno connesso al server reale (ma in questo caso i checksum non aiuteranno molto se li ottieni dallo stesso server falso)
- Un certo numero di ISP sono stati catturati iniettando Javascript nelle pagine in trasmissione per vari motivi ¹ ; a seconda di quanto bene sia implementato, potrebbe anche rovinare alcuni download di file
- Un mirror potrebbe ospitare una versione non aggiornata del file oppure l'amministratore potrebbe aver caricato il file errato
Assicurarsi che il file non sia stato danneggiato da qualcosa che TCP non è in grado di rilevare
- ad esempio, il file potrebbe essere danneggiato sul server, quindi TCP assicurerà solo che il file già danneggiato non sia stato ulteriormente alterato nella trasmissione
- oppure potrebbe essere danneggiato dopo l'arrivo, a causa di memoria / disco difettosi, driver del file system difettoso, ecc
- I checksum TCP sono solo a 16 bit, quindi le probabilità non sono astronomiche (1 su 65536) che un pacchetto corrotto non venga rilevato
Con un ISO, assicurando che il disco sia stato masterizzato correttamente

¹ fonti nel commento perché lol rep

— Rena
fonte

2

Fonti: * security.stackexchange.com/questions/70970/… * adblockplus.org/forum/viewtopic.php?t=8156 "ISP aggressivi iniettati / script incorporati / annunci bloccabili" * iamsrijit.wordpress.com/2012/09/ 14 /… * altri possono essere trovati facilmente su Google, ma non è proprio in tema qui

— Rena

2

Daniel, a seconda dello strumento che stai usando per il download ISO per dire. Se è Say Firefox .. Potrebbe mostrare il download del file. Tuttavia, potresti non avere la ISO completa. Se lo masterizzi, prova a usarlo, potrebbero mancare informazioni. Questo succede di volta in volta su diversi server web che ospitano file.

È buona norma confrontare almeno le dimensioni del file (byte o bit totali) per assicurarsi che corrispondano. Windows mostrerà il conteggio dei byte di file diverso quindi dire Linux. Il controllo di somma MD5 mostrerà gli stessi valori in nessun sistema operativo utilizzato. Spero che questo aiuti un po '. Saluti...

— David Thomson
fonte

2

Windows mostra il conteggio dei byte in modo diverso da come lo mostra Linux? Veramente? Ho pensato che l'addominio fosse uscito con il file system CP / M di dimensioni dei file come conteggio dei blocchi. (Ora, se stai guardando qualcosa di diverso dal conteggio dei byte - diciamo, la dimensione del file visualizzata in Explorer - potrebbe benissimo differire. Ma nessun amministratore di sistema sano dovrebbe controllare l'integrità del file scaricato in quel modo, quindi non è un problema.) I byte sono byte. Guardarlo in termini di bit, tuttavia, non ha senso; quando è stata l'ultima volta che hai scaricato e archiviato mezzo byte?

— un CVn

2

Noto molte risposte interessanti ma c'è un'ultima cosa da considerare: il problema dei due generali

Il problema dei due generali e il problema dei generali bizantini considerano specificamente le implicazioni del trasferimento affidabile di informazioni attraverso canali inaffidabili.

I checksum sono solo un altro livello di "crescente affidabilità" e uno con una probabilità molto ridotta di fallimento. Questo è il motivo per cui è così popolare.

— Fernando Cordeiro
fonte