Rilevamento per corruzione in HTTP e FTP [chiuso]

How is data downloaded from HTTP or FTP get checked for corruption?

Di per sé, per nulla .

I protocolli HTTP e FTP come non offrono integrità¹.

Tuttavia, HTTP e FTP vengono solitamente utilizzati in cima al TCP / IP, che hanno entrambi i checksum nei loro trasporti - se un checksum TCP fallisce, il sistema operativo scarterà semplicemente il pacchetto TCP e lo richiederà di nuovo. Quindi non c'è bisogno di HTTP per implementare anche il controllo di integrità.

Quando esegui il tunneling di qualsiasi cosa (incluso HTTP e FTP) su TLS, ottieni un ulteriore livello di controlli di integrità.

So how does FTP and HTTP ensure that data is not corrupt?

Non lo fanno. Di solito è compito del trasporto garantire l'integrità, non il lavoro del protocollo dell'applicazione.

Vorrei aggiungere che è ovviamente più difficile provocare una collisione all'interno di MD5 (che viene utilizzata in queste intestazioni) piuttosto che creare pacchetti TCP, se si volesse modificare intenzionalmente il trasferimento. Ma se questo è il tuo scenario di attacco, TLS è la risposta, non i checksum HTTP.

HTTP e FTP usano quasi sempre TCP come livello di trasporto sottostante, quindi anche le protezioni TCP si applicano. Questi, tuttavia, riguardano solo problemi di corruzione accidentale a livello di rete. Come fai notare, la verifica che il file sia stato scritto con successo è generalmente lasciato a un checksum come CRC32.

Se ti preoccupi della manipolazione intenzionale (che presumo tu sia, dato che è su security.SE), questi non sono sufficienti, perché non sono crittograficamente sicuri. Dal lato della rete, generalmente abbiamo a che fare con un diverso livello introducendo TLS (quando combinato con HTTP, otteniamo HTTPS ; quando combinato con FTP, otteniamo FTPS). Ma se vuoi essere particolarmente sicuro, oltre a verificare l'integrità del file che hai sul disco, un approccio comune per i fornitori è quello di fornire un file che elenca i checksum SHA-2, e quindi firmarlo con una chiave GPG; scarichi entrambi i file, quindi verifica che il file di checksum sia stato firmato da una chiave attendibile e che gli altri file corrispondano ai checksum elencati nel file appena verificato.

So how does FTP and HTTP ensure that data is not corrupt?

In breve, dal punto di vista della sicurezza, non lo fanno.

Tutti questi protocolli assumono stacked . E ogni livello nella pila ha la sua responsabilità. Ciò che è strano rispetto alla tua domanda è che l'integrità del messaggio non è né la preoccupazione di FTP o HTTP né quella di TCP. I primi sono responsabili della parte di alto livello del protocollo che consente di scambiare file o dati, quest'ultimo è responsabile della corretta consegna dei pacchetti. L'integrità dei pacchetti è la preoccupazione del livello 2 (collegamento dati) nello stack OSI. Dovrebbe garantire che un pacchetto scambiato tra 2 nodi consecutivi non sia stato alterato. Il protocollo più comune qui è HDLC che utilizza un solido checksum.

Ovviamente, esiste un checksum a livello di TCP, ma solo una caratteristica catch all deve essere avvisata nel caso in cui uno dei nodi impazzisca e invii dati errati, e usa un somma di controllo molto più debole. Dopotutto, l'integrità non è il suo lavoro.

Se si utilizzano reti normali , l'integrità dei dati è garantita dallo stack TCP / IP completo. I checksum end-to-end vengono normalmente utilizzati per controllare che il file non sia stato danneggiato nel sito del mittente o perché si utilizza un mirror o in caso di problemi sul file system di origine.