¿Se puede dañar accidentalmente un archivo al descargarlo?

2

Leí una respuesta aquí sobre sitios web que proporcionan archivos descargables junto con sus hashsums. Contuvo una oración en la que estoy pensando cada vez que descargo algo, pero realmente nunca lo entendí: The provided hash lets you double-check that the file you downloaded was not corrupted accidentally in transit .

Creo que puedo recordar vagamente que esto, tener que volver a descargar un archivo porque está dañado, sucedió a veces en el pasado, cuando sufrí un módem de 56k, y descargas donde me duele en general. Pero no estoy seguro de que esto haya ocurrido, y no pude explicarlo: hay TCP, que debería ser capaz de manejar mi descarga perfectamente, y está disponible desde al menos 1983.

¿Hay alguna forma en que un archivo descargado pueda diferir del archivo en el servidor, además de los ataques maliciosos como MITM? O: como usuario, si creo que algo no está bien con la descarga finalizada, ¿tiene que ser un ataque MITM?

    
pregunta stuXnet 30.10.2015 - 20:56
fuente

3 respuestas

1

Es posible pero poco común con HTTP que los bytes reales estén dañados. Pero no es raro que la descarga se interrumpa en el medio y que el navegador no se dé cuenta. Esto es especialmente cierto si no se envía información de longitud con el contenido (es decir, termina con el cierre de TCP), pero incluso si se envía una longitud o se utiliza una codificación fragmentada, los navegadores a menudo ignoran dichos errores.

Con FTP incluso vale la pena porque no hay una manera real de indicar la longitud del contenido, es decir, el contenido siempre termina con el cierre de la conexión. Aparte de eso, la corrupción puede ocurrir si utiliza el modo de transferencia ASCII incorrecto en lugar de BINARY.

    
respondido por el Steffen Ullrich 30.10.2015 - 21:39
fuente
0

Los errores de transmisión de paquetes pueden ocurrir y ocurren en tránsito. TCP corrige la mayoría de los errores antes de que lleguen al archivo, pero incluso TCP no es perfecto. La suma de comprobación de TCP es solo de 16 bits, y ciertamente es posible que un error introducido aleatoriamente pase la suma de comprobación por coincidencia.

Este documento dice que de 1 en 16 millones a 1 en 10 mil millones de paquetes no detectará un error de transmisión. Aunque es raro, todavía es útil tener algún medio de controles adicionales.

    
respondido por el Steve Sether 30.10.2015 - 21:32
fuente
0

Los intermediarios de la capa de aplicación, como los cachés HTTP, pueden manipular los datos en una sesión HTTP sin cifrar sin ninguna forma general de detectarlos. Cualquier enrutador intermediario puede hacer lo mismo en la capa TCP.

Los errores de TCP también pueden ocurrir, pero como las otras respuestas han identificado, esto no es muy común.

No se puede confiar en las descargas en transportes de baja / sin integridad como HTTP y FTP. La verificación adicional con GPG / PGP o firma similar mitiga esto, asumiendo que las claves que está verificando se descargaron o se obtuvieron de forma segura.

La descarga a través de TLS (asumiendo certificados válidos y CAcerts sensibles localmente) resuelve efectivamente el primer problema. Proporciona integridad y confidencialidad. También mitiga sustancialmente el segundo problema, ya que los errores silenciosos de TCP fallarían en la capa TLS.

    
respondido por el Alain O'Dea 30.10.2015 - 21:57
fuente

Lea otras preguntas en las etiquetas