Detección de corrupción en HTTP y FTP [cerrado]

  

¿Cómo se verifica la corrupción de los datos descargados de HTTP o FTP?

Por sí mismo, nada .

HTTP y FTP ya que los protocolos no ofrecen integridad¹.

Sin embargo, HTTP y FTP generalmente se usan sobre TCP / IP, que tienen sumas de comprobación en sus transportes. Si falla una suma de comprobación TCP, su sistema operativo simplemente descartará el paquete TCP y lo solicitará nuevamente. Por lo tanto, no es necesario que HTTP implemente incluso la verificación de integridad.

Al canalizar algo (incluidos HTTP y FTP) a través de TLS, obtiene una capa adicional de controles de integridad.

  

Entonces, ¿cómo FTP y HTTP se aseguran de que los datos no estén dañados?

No lo hacen. Normalmente, el trabajo del transporte es garantizar la integridad, no el trabajo del protocolo de la aplicación.

Me gustaría agregar aquí que, por supuesto, es más difícil causar una colisión dentro de MD5 (que se usa en estos encabezados) que forjar paquetes TCP, si desea modificar la transferencia intencionalmente. Pero si ese es su escenario de ataque, TLS es la respuesta, no las sumas de comprobación HTTP.

HTTP y FTP casi siempre usan TCP como la capa de transporte subyacente, por lo que las protecciones de TCP también se aplican allí. Estos, sin embargo, solo están relacionados con problemas de corrupción accidental a nivel de red. Como señala, la verificación de que el archivo se escribió con éxito generalmente se deja en una suma de comprobación como CRC32.

Si está preocupado por la manipulación intencional (que supongo que usted es, ya que está en security.SE), esto no es suficiente, porque no son criptográficamente seguros. En el lado de la red, generalmente estamos tratando con una capa diferente al introducir TLS (cuando se combina con HTTP, obtenemos HTTPS ; cuando se combina con FTP, obtenemos FTPS). Pero si desea estar particularmente seguro, así como verificar la integridad del archivo que tiene en el disco, un enfoque común para los proveedores es proporcionar un archivo con las sumas de comprobación SHA-2 y luego firmarlo con una clave GPG; descarga ambos archivos, luego verifica que el archivo de sumas de comprobación haya sido firmado por una clave en la que confíes y que el / los otro (s) archivo (s) coincidan con las sumas de verificación enumeradas en el archivo que acabas de verificar.

  

Entonces, ¿cómo FTP y HTTP se aseguran de que los datos no estén dañados?

En resumen, desde una perspectiva de seguridad, no lo hacen.

Todos esos protocolos se suponen apilados . Y cada nivel en la pila tiene su propia responsabilidad. Lo que es extraño en relación con su pregunta es que la integridad del mensaje no es una preocupación de FTP o HTTP ni la de TCP. Los primeros son responsables de la parte de alto nivel del protocolo que permite intercambiar archivos o datos, el último es responsable de la entrega correcta de los paquetes. La integridad de los paquetes es la preocupación de la capa de nivel 2 (enlace de datos) en la pila OSI. Debe garantizar que un paquete intercambiado entre 2 nodos consecutivos no haya sido alterado. El protocolo más común aquí es HDLC, que utiliza una suma de comprobación sólida.

Por supuesto, hay una suma de comprobación en el nivel de TCP, pero solo una característica de capturar todo para ser alertada en caso de que uno de los nodos se haya vuelto loco y envíe datos erróneos, y utiliza una suma de control mucho más débil. Después de todo, la integridad no es su trabajo.

Si utiliza redes normales , la pila de TCP / IP garantiza la integridad de los datos. Las sumas de comprobación de extremo a extremo se utilizan normalmente para controlar que el archivo no se haya dañado en el sitio del remitente, ya sea porque utiliza un espejo o en caso de un problema en el sistema de archivos original.