Perché calcolare i checksum dei file scaricati?

Vedo spesso un checksum accanto a un file disponibile per il download. Lo scopo di questa pratica mi sfugge. È ovviamente per rilevare i file corrotti, ma quale potrebbe essere la causa di questa corruzione ed è del tutto probabile?

Sicuramente il file non sarà danneggiato da errori di trasmissione poiché questi sono rilevati dal protocollo di rete. E sicuramente qualsiasi utente malintenzionato che potrebbe modificare il file per scopi dannosi potrebbe anche modificare il checksum indicato. Stiamo verificando errori sul disco rigido? È più probabile che accada quando si scrive e poi quando si legge? Mi sto perdendo qualcosa di importante?

Rilevare la corruzione non è del tutto corretto. Per accertare l'integrità del software sarebbe un uso più corretto. Normalmente un software non è distribuito da un singolo server. Lo stesso software può essere distribuito da molti server. Pertanto, quando scarichi un determinato software, il server più vicino alla tua destinazione viene scelto come fonte di download per aumentare la velocità di download. Tuttavia, questi server "non ufficiali" (di terze parti) non sono sempre affidabili. Potrebbero / possono includere trojan / virus / adware / backdoor nel programma, il che non va bene .

Pertanto, per garantire che il software scaricato sia esattamente uguale a quello del software "ufficiale" rilasciato dall'organizzazione interessata, viene utilizzato il checksum. Gli algoritmi utilizzati per la generazione di checksum sono tali che anche un leggero cambiamento nel programma si traduce in un checksum completamente diverso.

Esempio tratto da Practical Unix e Internet Security

MD5 (ci sono $ 1500 nella casella blu.) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (ci sono $ 1100 nella casella blu.) = D6dee11aae89661a45eb9d21e30d34cb

I messaggi, che differiscono per un solo carattere (e, all'interno di quel carattere, per un solo bit binario), hanno digest dei messaggi completamente diversi.

Se il file scaricato ha lo stesso checksum del checksum fornito sul sito Web "ufficiale", si può presumere che il software non sia modificato.

Nota a margine: in teoria, due file diversi POSSONO avere lo stesso valore di hash. Affinché l'algoritmo Hash / checksum sia considerato sicuro, dovrebbe essere molto costoso dal punto di vista computazionale trovare un altro file che produca lo stesso checksum.

E sicuramente qualsiasi utente malintenzionato che potrebbe modificare il file per scopi dannosi potrebbe anche modificare il checksum indicato.

Non sempre.

È possibile disporre di un collegamento al contenuto insieme a un checksum pubblicato su HTTPS. Il collegamento potrebbe essere un collegamento non crittografato: semplice HTTP o FTP o qualcos'altro.

Il rovescio della medaglia, la connessione non crittografata può diventare facilmente di mezza età, al contrario, può essere più veloce o più conveniente per il webmaster (meno risorse di elaborazione necessarie e opportunità per la rete di memorizzare nella cache).

Se il checksum viene servito su una connessione affidabile ininterrotta e il payload corrisponde al checksum, si ottiene il meglio da entrambi i mondi (a condizione che il checksum sia crittograficamente sicuro).

Detto questo, mi hai ricordato che ci sono distro là fuori che affermano di essere "sicuri" e tuttavia il loro sito Web è solo su HTTP, così come i collegamenti alle loro immagini.

Esempi:

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

È un po 'divertente perché non puoi assolutamente essere più insicuro di quello. Anche se non sono maliziosi, qualsiasi ISP potrebbe facilmente sostituire sia il sito Web che l'immagine con falsi, e convincere qualcuno a installare un sistema operativo truccato facendo sembrare che stiano ottenendo una distribuzione Linux "sicura" è il massimo Pwnage.

Per quanto riguarda il motivo per cui il controllo degli errori TCP / IP non rileva tutto: da /programming//a/17083365/2551539

Possono verificarsi diversi errori (che TCP rileverà) [sottolineato da Jacob Krall] :

• Ordine errato dei pacchetti
• Perdita di pacchetti
• Dati danneggiati all'interno del pacchetto
• Pacchetti fantasma (il destinatario riceve pacchetti che non sono mai stati inviati)

Modifica con alcune informazioni aggiuntive:

Pagina 9 di questo studio: http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf suggerisce che ci sono errori che possono non essere rilevati da TCP. La mia comprensione è che accade quando un datagramma errato (chiamato "cattivo gemello" nello studio) ha lo stesso checksum del datagramma desiderato (chiamato "buono gemello" nello studio).

Possono verificarsi errori di trasmissione. I protocolli a livello di link in genere contengono checksum o codici di correzione degli errori per evitarli, ma non sono perfetti: c'è una piccola possibilità che un errore non venga corretto. I pacchetti TCP contengono anche un checksum, che riduce la probabilità di errori di 2 ^ 16. Ciò crea una probabilità molto piccola, ma diversa da zero, di un errore di trasmissione. È il genere di cose che la maggior parte delle persone non incontrerà mai inconsapevolmente nel corso della propria vita, ma non è nella gamma di verifiche crittografiche mai compresa tra un miliardo di anni.

È improbabile che venga rilevato un errore hardware sul client, come il danneggiamento del disco, verificandolo subito dopo il download, poiché il checksum verrà calcolato dalla copia memorizzata nella cache. Controllare il supporto di avvio per corruzione se non si sono avviati è utile, d'altra parte - stai davvero testando il supporto e hai il presupposto che l'hardware potrebbe essere difettoso.

Il vero motivo per calcolare i checksum è infatti rilevare errori a livello di software. Questi accadono. I possibili errori includono:

• Un file è stato parzialmente scaricato. I server Web e i browser tendono a essere difettosi nel rilevare connessioni interrotte e nel ripulire i file parziali. L'errore potrebbe essere durante il download o durante il caricamento, aggiunge.
• C'è stata della corruzione lungo la strada. Ad esempio, alcuni nodi intermedi nella distribuzione del file hanno deciso di applicare una conversione di codifica di testo a un file binario. Oppure un server non configurato correttamente ha visualizzato un messaggio di errore anziché il contenuto.
• Una variante: è stato caricato il file sbagliato.
• Raro, ma può essere utile per proteggersi: un avversario ha cambiato il file ma non è stato in grado di modificare il checksum di riferimento. Le infrastrutture di sicurezza tendono a rendere più difficile per un utente malintenzionato la propagazione di un checksum non valido rispetto a un file non valido. Ad esempio, i file di grandi dimensioni sono spesso distribuiti attraverso mirror, mentre i checksum sono serviti da un sito centrale con minori opportunità di manomissione (accesso al server solo ai project leader, distribuzione tramite HTTPS).

In pratica, il controllo della dimensione del file scaricato rileva gli errori più comuni, che sono file troncati o convertiti in modo non valido. I checksum hanno il vantaggio di rilevare rigorosamente più problemi.

In teoria, la rete fornirebbe correttamente ogni singolo segmento e verrebbero assemblati correttamente sul disco e nulla andrebbe storto.

In realtà, i computer sono macchine e software, entrambi progettati e costruiti da umani fallibili. Nel caso in cui un download in qualche modo non scenda correttamente per una ragione o per l'altra, come ad esempio il download tramite un dispositivo intermedio sia innocuo o nefasto che manipola i dati, è bello avere un modo per verificare che il file sia quasi sicuramente scaricato come una replica accurata del file sul lato del provider.

Un checksum di alta qualità è un metodo affidabile per convalidare l'integrità dei dati.

Nessun checksum può essere affidabile al 100% perché molti file sono associati allo stesso checksum.

Quando aggiungiamo un altro checksum al treno si moltiplica la probabilità di rilevare un errore.

C'è così tanto traffico su Internet che gli errori sono in realtà abbastanza comuni.

Checksum aiuterà anche a prevenire il download danneggiato a causa della seguente situazione:

Il server ha un errore interno durante il download, quindi il download è terminato.

Quando ciò accade, ci sono alcuni possibili esiti:

• Buon server : l'implementazione del server della codifica di trasferimento Chunked non è errata:
  • Un buon client (come cURL, wget) sarà in grado di informarti che si tratta di un download errato poiché il blocco di terminazione non è mai stato inviato dal server.
  • Il client errato penserà che il download sia stato completato poiché dal server non vengono ricevuti altri dati.
• Server danneggiato: l'implementazione del server della codifica di trasferimento Chunked è errata e invia il blocco di terminazione per questo download errato:
  • Qualsiasi client penserà che questo download sia stato completato correttamente.

Ho visto questi comportamenti tra i più diffusi strumenti client e framework di server, quindi quando non usi il checksum, allora nel caso di "server buono + client cattivo" o "server cattivo + qualsiasi client", il download corrotto verrà notato .