9

To verify, that the files I have downloaded using it are not corrupted.

peterh
  • 2,938
  • 6
  • 25
  • 31
Ulkoma
  • 8,793
  • 16
  • 65
  • 95
  • corrupted at what point? – schroeder Feb 02 '15 at 22:48
  • Sometimes I end up with files on my PC that have different checksums than the corresponding ones on the server – Ulkoma Feb 02 '15 at 22:49
  • 2
    @Ulkoma Actually, TCP has a minimal checksum feature, I don't know why it doesn't work, maybe you could ask it in a new question. – peterh Feb 02 '15 at 23:06
  • From your comments/answers I conclude that if I ONLY have ftp access to the server this means there is no way for me to verify the integrity of the files I download apart from comparing the sizes. – Ulkoma Feb 03 '15 at 11:47

3 Answers3

8

No, FTP does not include integrity protection as a feature of the protocol. You can use SFTP which runs over SSH and does have built-in integrity checks (scp is another option that uses SSH).

You can roll your own integrity protection by manually comparing a checksum calculated locally with one calculated either on the remote host itself or by the origin client who uploaded it. MD5 is a typical choice, and you can calculate the MD5 checksum by running openssl md5 <file> on most Unix-like systems.

If you can't use SSH, hopefully that means you have no remote shell access at all. If that is true, then you would need to compute the checksum prior to uploading the file, then store it somewhere (e.g. md5.txt) for future reference. That assumes that you are the one uploading the files which may not be the case.

AJAr
  • 1,682
  • 1
  • 9
  • 19
  • Any way to compare the files I download to the ones on the server? – Ulkoma Feb 02 '15 at 22:57
  • 2
    @Ulkoma Theoretically, the protocol could be extended by new commands - actually, the ftp protocol is very similar to some shell commands. For example, you could create an "md5" command, but it were an extension to the ftp and not the ftp. The ftp "standard" (an RFC) doesn't contains anything from that. – peterh Feb 02 '15 at 23:03
  • 1
    Have you looked at rsync? – wireghoul Feb 03 '15 at 02:19
  • 1
    Why are we still talking about md5 hashes? SHA is the way to go. – multithr3at3d Jan 10 '16 at 04:49
  • Generally, although either one should work for integrity protection. – AJAr Jan 16 '16 at 21:43
  • I don't understand. Isn't FTP based on TCP and then provides data integrity support ? Every network packet is supposed to clean of error, aren't they ? – Kii Jun 21 '16 at 09:25
  • 1
    @Kii That's a great question, actually. Let's consider why integrity checks exist in transport protocols at all, and really there are only two reasons. The first reason is just incidental data corruption — out-of-order, MIA data, etc. — and you're right that TCP provides some protection in that scenario. The other scenario, more a concern of InfoSec, is malicious corruption of data moving in either direction. If you went to grab an executable file from FTP, none of the underlying protection would notice or correct that the bytes you got were the bytes intended by either the client or server. – AJAr Jun 22 '16 at 23:22
7

There is an IETF Draft which defines a new HASH command for FTP, to address these sorts of needs. Some FTP servers have support for HASH, as well as some of the earlier commands of this sort, e.g. XCRC, XMD5, XSHA1, etc. And some FTP clients, such as SmartFTP, use these commands when available.

Community
  • 1
Castaglia
  • 560
  • 8
  • 19
-1

If using SFTP, you will need to do this though SSH. Just a note!

But to answer the question, no ftp does not provide security (integrity) of any sort. It uses ports 20 and 21 which both transmit data openly.

With SFTP which is an SSH protocol port 22 is used.

Rio Hazuki
  • 55
  • 2