Un file può essere danneggiato accidentalmente durante il download?

Question

Un file può essere danneggiato accidentalmente durante il download?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

2

Ho letto una risposta qui sui siti Web che forniscono file scaricabili insieme ai relativi hashsum. Conteneva una frase a cui pensavo ogni volta che scaricavo qualcosa, ma non l'ho mai veramente capito: The provided hash lets you double-check that the file you downloaded was not corrupted accidentally in transit .

Penso di potermi ricordare vagamente che questo, dover scaricare di nuovo un file perché è rotto, è successo qualche volta in passato, quando ho sofferto di un modem 56k, e scarica dove c'è un dolore in generale. Ma non sono sicuro che sia successo, e non ho potuto spiegarlo - c'è il TCP, che dovrebbe essere in grado di gestire il mio download perfettamente bene, ed è in circolazione almeno dal 1983.

C'è un modo in cui un file scaricato può differire dal file sul server, oltre agli attacchi malevoli come il MITM? Oppure: come utente, se penso che qualcosa non sia giusto per il download finito, deve essere un attacco MITM?

man-in-the-middle integrity

posta stuXnet 30.10.2015 - 20:56

fonte

3 risposte

Leggi altre domande sui tag man-in-the-middle integrity

Area di superficie di attacco WebRTC? Esegui fuzzer su qualsiasi servizio o processo in Linux

score 1 · Answer 1

È possibile, ma non comune con HTTP, che i byte effettivi siano corrotti. Ma non è raro che il semplice download si interrompa in mezzo e che il browser non si accorga. Ciò è particolarmente vero se non vengono inviate informazioni di lunghezza con il contenuto (vale a dire termina con TCP close) ma anche se viene inviata una lunghezza o viene utilizzata la codifica chunked, i browser spesso ignorano tali errori.

Con FTP vale anche perché non esiste un modo reale per indicare la lunghezza del contenuto, cioè il contenuto finisce sempre con la chiusura della connessione. A parte questo, la corruzione può accadere se si utilizza la modalità di trasferimento errata ASCII anziché BINARY.

score 0 · Answer 2

Gli errori di trasmissione del pacchetto possono e si verificano durante il trasporto. Il TCP corregge la maggior parte degli errori prima che arrivino al file, ma anche il TCP non è perfetto. Il checksum TCP ha solo 16 bit, ed è certamente possibile che un errore introdotto casualmente passi in modo casuale il checksum.

Questo documento dice che ovunque da 1 su 16 milioni a 1 su 10 miliardi di pacchetti non riuscirà a rilevare un errore di trasmissione. Anche se è raro, è comunque utile disporre di alcuni strumenti per controlli aggiuntivi.

score 0 · Answer 3

Gli intermediari del livello di applicazione come le cache HTTP possono manipolare i dati in una sessione HTTP non crittografata senza alcun modo generale di rilevarli. Qualsiasi router intermedio può fare lo stesso sul livello TCP.

Si possono anche verificare errori TCP, ma come le altre risposte hanno identificato questo è molto raro.

Non è possibile fidarsi dei download su trasporti a bassa / nessuna integrità come HTTP e FTP. Ulteriori verifiche con GPG / PGP o firme simili attenuano questo presupponendo che le chiavi che stai verificando siano state scaricate o ottenute in altro modo in modo sicuro.

Il download su TLS (assumendo certificati validi e CAcert sensibili localmente) risolve efficacemente il primo problema. Fornisce integrità e riservatezza. Inoltre, attenua sostanzialmente il secondo problema dato che errori TCP invisibili non riuscirebbero sul livello TLS.