Los sitios web que proporcionan archivos ISO para descargar a menudo proporcionarán sumas de verificación md5 de esos archivos, que podemos usar para confirmar que el archivo se ha descargado correctamente y no está dañado.
¿Por qué es esto necesario? Seguramente las propiedades de corrección de errores de TCP son suficientes. Si un paquete no se recibe correctamente, será retransmitido. ¿La propia naturaleza de una conexión TCP/IP no garantiza la integridad de los datos?
Respuesta1
Como han señalado otros, existen muchas posibilidades de corrupción de datos en las que cualquier suma de verificación en la capa de transporte no puede ayudar, como que la corrupción ocurra ya antes de que se calcule la suma de verificación en el lado emisor, un MITM intercepte y modifique el flujo (también los datos). como sumas de verificación), la corrupción ocurre después de validar la suma de verificación en el extremo receptor, etc.
Si ignoramos todas estas otras posibilidades y nos centramos en los detalles específicos delSuma de comprobación TCPen sí y lo que realmente hace en términos de validar la integridad de los datos, resulta que las propiedades de esta suma de verificación no son del todo exhaustivas en términos de detección de errores. La forma en que se eligió este algoritmo de suma de control refleja más bien el requisito de velocidad en combinación con el período de tiempo (finales de la década de 1970).
Así es como elSuma de comprobación TCPes calculado:
Suma de comprobación: 16 bits
El campo de suma de comprobación es el complemento a uno de 16 bits de la suma en complemento a uno de todas las palabras de 16 bits en el encabezado y el texto. Si un segmento contiene un número impar de octetos de encabezado y texto que deben sumarse, el último octeto se rellena a la derecha con ceros para formar una palabra de 16 bits a efectos de suma de verificación. El pad no se transmite como parte del segmento. Mientras se calcula la suma de verificación, el campo de suma de verificación se reemplaza por ceros.
Esto significa que cualquier corrupción que se equilibre al sumar los datos de esta manera no se detectará. Hay una serie de categorías de corrupción de datos que esto permitirá, pero solo como un ejemplo trivial: cambiar el orden de las palabras de 16 bits siempre pasará desapercibido.
En la práctica, detecta muchos errores típicos pero no *garantiza* la integridad en absoluto. También ayuda el hecho de que la capa L2 también realiza comprobaciones de integridad (por ejemplo, CRC32 de tramas Ethernet), aunque solo para la transmisión en el enlace local, y muchos casos de datos corruptos ni siquiera pasan a la pila TCP.
Validar los datos utilizando un hash fuerte, o preferiblemente una firma criptográfica, está en un nivel completamente diferente en términos de garantizar la integridad de los datos. Los dos apenas se pueden comparar.
Respuesta2
Probablemente hay millones de razones por las que uno debería comprobar la suma md5, pero me vienen a la mente algunas:
- Actividad maliciosa: su ISO podría haber sido manipulado en el camino desde el servidor
- La página en sí está falsificada (es mejor tener los md5sums firmados también :))
- Descarga interrumpida (a pesar de la corrección de errores de TCP) (verifiqueesteafuera)
- ISO quemado incorrectamente
Y de todos modos sólo lleva unos segundos.
Respuesta3
TCP/IP garantiza la integridad de los datos*. Pero no garantiza que se haya descargado el 100% de un archivo. Puede haber muchas razones por las que esto podría suceder. Por ejemplo: es posible que puedas montar una ISO a la que le falten uno o dos bytes en algún punto intermedio. No tendrás ningún problema con él hasta que necesites uno o dos archivos específicos que estén corruptos. La comparación de sumas de verificación garantiza que realmente haya descargado el archivo completo.
* Ver comentario
Respuesta4
Hay varias razones para verificar la suma de comprobación de un archivo descargado mediante HTTP:
- Asegurarse de haber recibido el archivo completo
- Algunos clientes, comoFirefox, puede tratar una conexión interrumpida como una descarga exitosa, dejándolo con un archivo truncado pero afirmando que se descargó correctamente.
- Asegurarse de haber recibido el archivo correcto
- por ejemplo, un servidor defectuoso, comprometido o malicioso podría enviarle algo más
- alguien podría alterar la transferencia (ataque de intermediario); ni siquiera HTTPS está a salvo de esto si su sistema está comprometido, por ejemplo, con Superfish, o si el método de cifrado utilizado es débil
- También podrían presentarte una página de descarga falsa, por lo que ni siquiera estás conectado al servidor real (pero en este caso las sumas de verificación no ayudarán mucho si las obtienes del mismo servidor falso).
- Varios ISP han sido sorprendidos inyectando Javascript en páginas en transmisión por diversas razones 1 ; Dependiendo de qué tan bien se implemente esto, también podría dañar algunas descargas de archivos.
- Es posible que una réplica albergue una versión desactualizada del archivo o que el administrador haya subido el archivo incorrecto.
- Asegurarse de que el archivo no esté dañado por algo que TCP no pueda detectar
- por ejemplo, el archivo podría estar dañado en el servidor, por lo que TCP solo garantizará que el archivo ya dañado no se estropee más durante la transmisión.
- o podría corromperse después de llegar a su lado, por memoria/disco defectuoso, controlador de sistema de archivos defectuoso, etc.
- Las sumas de comprobación de TCP son sólo de 16 bits, por lo que las posibilidades no son astronómicas (1 entre 65536) de que no se detecte un paquete corrupto.
- Con una ISO, asegurando que el disco se grabó correctamente
1 fuentes en el comentario porque jajaja rep.