¿Por qué calcular sumas de verificación de archivos descargados?

19

A menudo veo una suma de comprobación junto a un archivo disponible para descargar. El propósito de esta práctica me elude. Obviamente es para detectar archivos corruptos, pero ¿cuál podría ser la causa de esta corrupción y es probable?

Seguramente el archivo no será dañado por errores de transmisión, ya que son detectados por el protocolo de red. Y seguramente cualquier atacante que pueda alterar el archivo con fines maliciosos también podría alterar la suma de verificación dada. ¿Estamos buscando errores en el disco duro? ¿Es más probable que eso suceda al escribir que al leer? ¿Me estoy perdiendo algo importante?

networking files checksum

— Karolis Juodelė
fuente

2

Y seguramente cualquier atacante que pueda alterar el archivo con fines maliciosos también podría alterar la suma de verificación dada. - De acuerdo, una suma de verificación no garantiza la autenticidad si no se sirve a través de HTTPS, o si no está seguro de que el certificado SSL pertenece al creador del software.

— Mihai

1

La suma de verificación TCP es realmente bastante pésima: solo tiene 16 bits. Si está sirviendo archivos grandes a miles de personas (piense: imágenes de DVD de instalación), es prácticamente seguro que algunas de esas descargas se corromperán indetectablemente.

— Mark

@Mihai Por supuesto, probablemente disminuya un poco el riesgo. Por ejemplo, si su servidor está infectado por un virus que modifica automáticamente todas las respuestas binarias (o simplemente reemplaza todos los ejecutables que descarga). No es perfecto, pero puede ayudar en algunos casos.

— Luaan

9

Detectar corrupción no es del todo correcto. Determinar la integridad del software sería un uso más correcto. Normalmente, un software no se distribuye desde un único servidor. El mismo software puede distribuirse desde muchos servidores. Entonces, cuando descarga un software en particular, el servidor más cercano a su destino se elige como fuente de descarga para aumentar la velocidad de descarga. Sin embargo, no siempre se puede confiar en estos servidores 'no oficiales' (de terceros). Pueden / pueden incluir troyanos / virus / adware / puertas traseras en el programa, lo que no es bueno .

Por lo tanto, para garantizar que el software descargado sea exactamente el mismo que el software 'oficial' lanzado por la organización en cuestión, se utiliza la suma de comprobación. Los algoritmos utilizados para generar sumas de verificación son tales que incluso un ligero cambio en el programa da como resultado una suma de verificación completamente diferente.

Ejemplo tomado de Practical Unix e Internet Security

MD5 (Hay $ 1500 en el cuadro azul) = 05f8cfc03f4e58cbee731aa4a14b3f03

MD5 (Hay $ 1100 en el cuadro azul) = d6dee11aae89661a45eb9d21e30d34cb

Los mensajes, que difieren en un solo carácter (y, dentro de ese carácter, en un solo bit binario), tienen resúmenes de mensajes completamente diferentes.

Si el archivo descargado tiene la misma suma de comprobación que la suma de comprobación proporcionada en el sitio web "oficial", se puede suponer que el software no se ha modificado.

Nota al margen: en teoría, dos archivos diferentes PUEDEN tener el mismo valor hash. Para que el algoritmo Hash / suma de verificación se considere seguro, debería ser muy costoso desde el punto de vista informático encontrar otro archivo que produzca la misma suma de verificación.

— Aswin PJ
fuente

1

Entonces, si el archivo y la suma de comprobación son proporcionados por el mismo host, ¿es algo inútil?

— Karolis Juodelė

Tal vez. La suma de verificación es solo un medio para determinar la integridad. Digamos que en un escenario particular, si un atacante obtiene acceso al servidor FTP de la organización, podría alterar el software. Pero aún puede usar la misma suma de verificación para determinar la integridad SI Y SOLO SI el atacante no ha entrado en el servidor HTTP. Entonces, si ambos están bajo el control del atacante, él puede alterarlos fácilmente y usted no notaría la diferencia.

— Aswin PJ

1

Otra situación en la que la suma de comprobación puede ser relevante es detectar situaciones en las que se reanuda la transferencia de un archivo después de un problema pero el archivo se ha cambiado mientras tanto.

— supercat

@ KarolisJuodelė El enlace de descarga puede estar en el mismo sitio web / host. Pero Where to resuelve podría ser diferente según el servidor más cercano. También tenga en cuenta que la página de suma de comprobación debe ser https, mientras que la descarga puede ser cualquier protocolo http o ftp

— balki

10

Y seguramente cualquier atacante que pueda alterar el archivo con fines maliciosos también podría alterar la suma de verificación dada.

No siempre.

Podría tener un enlace de contenido junto con una suma de verificación servida en HTTPS. El enlace podría ser un enlace no encriptado: HTTP o FTP simple, u otra cosa.

En el lado negativo, la conexión no encriptada puede ser fácilmente intermedia, por el lado positivo, puede ser más rápida o más conveniente para el webmaster (menos recursos informáticos necesarios y oportunidades para que la red guarde en caché esas cosas).

Si la suma de verificación se sirve en una conexión de confianza ininterrumpida y la carga útil coincide con la suma de verificación, obtendrá lo mejor de ambos mundos (siempre que la suma de verificación sea criptográficamente segura).

Dicho esto, me ha recordado que existen distribuciones que afirman ser "seguras" y, sin embargo, su sitio web está solo en HTTP, al igual que los enlaces a sus imágenes.

Ejemplos:

Es algo gracioso porque no puedes ser más inseguro que eso. Incluso si no son maliciosos, cualquier ISP podría reemplazar fácilmente tanto el sitio web como la imagen con falsificaciones, y lograr que alguien instale un sistema operativo manipulado mientras hace que parezca que están obteniendo una distribución Linux "segura" es lo último pwnage

— PSkocik
fuente

1

Hay muchas cosas menos seguras que HTTP no autenticado, que requiere un MITM activo para subvertir.

— user253751

4

En cuanto a por qué la comprobación de errores de TCP / IP no atrapa todo: desde /programming//a/17083365/2551539

Hay diferentes errores que pueden ocurrir (que TCP detectará) [señalado por Jacob Krall] :

Orden incorrecto de los paquetes.
Pérdida de paquetes
Datos corruptos dentro del paquete
Paquetes fantasma (el receptor recibe paquetes que nunca se han enviado)

Edite con alguna información adicional:

La página 9 de este estudio: http://paperhub.s3.amazonaws.com/8ff1e4414c070e900da8ab3885593085.pdf sugiere que hay errores que TCP no puede detectar. Entiendo que sucede cuando un datagrama erróneo (llamado "gemelo malo" en el estudio) tiene la misma suma de verificación que el datagrama deseado (llamado "gemelo bueno" en el estudio).

— Jesse Adam
fuente

2

Lea esa respuesta con más cuidado: esos son todos los errores que corrige TCP.

— Jacob Krall

4

Los errores de transmisión pueden suceder. Los protocolos de capa de enlace generalmente contienen sumas de verificación o códigos de corrección de errores para evitarlos, pero no son perfectos: existe una pequeña posibilidad de que un error no se corrija. Los paquetes TCP también contienen una suma de verificación, que reduce la probabilidad de errores en 2 ^ 16. Eso hace una probabilidad muy pequeña, pero no nula, de un error de transmisión. Es el tipo de cosas que la mayoría de las personas nunca encontrarán sin saberlo en su vida, pero no está en el rango de probabilidad de sumas de verificación criptográficas que nunca en un billón de años.

Es poco probable que se detecte un error de hardware en el cliente, como la corrupción del disco, al verificarlo inmediatamente después de la descarga, ya que la suma de comprobación se calculará a partir de la copia en caché. Por otro lado, es útil verificar si los medios de arranque no están dañados si no han podido arrancar: realmente está probando los medios y tiene la presuposición de que el hardware puede ser malo.

La verdadera razón para calcular sumas de verificación es, de hecho, detectar errores a nivel de software. Estos suceden. Los posibles errores incluyen:

Un archivo se descargó parcialmente. Los servidores web y los navegadores tienden a ser malos para detectar conexiones interrumpidas y limpiar archivos parciales. El error podría ser durante su descarga, o podría haber sido durante la carga, se suma.
Hubo algo de corrupción en el camino. Por ejemplo, algún nodo intermedio en la distribución del archivo decidió aplicar una conversión de codificación de texto a un archivo binario. O algún servidor mal configurado sirvió un mensaje de error en lugar del contenido.
Una variante: se cargó el archivo incorrecto.
Raro, pero puede ser útil para protegerse: un adversario cambió el archivo pero no pudo cambiar la suma de verificación de referencia. Las infraestructuras de seguridad tienden a dificultar que un atacante propague una suma de comprobación no válida que un archivo no válido. Por ejemplo, los archivos grandes a menudo se distribuyen a través de espejos, mientras que las sumas de verificación son atendidas por un sitio central con menos oportunidades de manipulación (acceso del servidor solo a los líderes del proyecto, distribución a través de HTTPS).

En la práctica, al verificar el tamaño del archivo descargado se detectan los errores más comunes, que son archivos truncados o convertidos de forma no válida. Las sumas de verificación tienen la ventaja de que detectan estrictamente más problemas.

— Gilles 'SO- deja de ser malvado'
fuente

2

En teoría, la red entregaría cada segmento correctamente y se ensamblarían correctamente en el disco y nada saldría mal.

En realidad, las computadoras son máquinas y software, ambos diseñados y construidos por humanos falibles. En el caso de que una descarga de alguna manera no se realice correctamente por una razón u otra, como que la descarga se realice a través de algún dispositivo intermediario, ya sea inocuo o nefasto, que manipula los datos, es bueno tener una manera de verificar que el archivo casi seguro descargado como una réplica precisa del archivo en el lado del proveedor.

Una suma de verificación de alta calidad es un método confiable para validar la integridad de los datos.

— Jason
fuente

0

Ninguna suma de verificación puede ser 100% confiable porque muchos archivos se asignan a la misma suma de verificación.

Cuando agregamos otra suma de verificación al tren, multiplicamos la probabilidad de detectar un error.

Hay tanto tráfico en Internet que los errores son bastante comunes.

— chasly del Reino Unido
fuente

También hay un poco de podredumbre.

— Deer Hunter

Lo cual debería ser detectado por el hardware de almacenamiento en sí, pero la suma de verificación es una característica clave de ZFS y btrfs, dudo que esté funcionando perfectamente.

— Max Ried

0

Checksum también ayudará a evitar descargas corruptas debido a la siguiente situación:

El servidor tiene un error interno mientras sirve la descarga, por lo tanto, la descarga finaliza.

Cuando eso sucede, hay algunos resultados posibles:

Buen servidor - la aplicación del servidor de codificación de transferencia fragmentada es no con errores:
- Un buen cliente (como cURL, wget) podrá informarle que esta es una descarga incorrecta ya que el fragmento de terminación nunca se ha enviado desde el servidor.
- Un cliente malo pensará que la descarga se ha completado ya que no se reciben más datos del servidor.
Servidor defectuoso: la implementación del servidor de la codificación de transferencia Chunked tiene errores, ya que envía el fragmento de terminación para esta descarga incorrecta:
- Cualquier cliente pensará que esta descarga se ha completado con éxito.

He visto estos comportamientos entre las herramientas de cliente populares y los marcos de servidores, por lo que cuando no use la suma de verificación, en el caso de "buen servidor + cliente malo" o "servidor malo + cualquier cliente", su descarga corrupta pasará desapercibida .