hash support?

[eddie1]

Hi everyone,

As of 2023, do FileZilla Server and FileZilla Client support each other for hash value checking? How can this feature be enabled?

I know that FileZilla Server can enable this feature by modifying FileZilla Server.xml, but does FileZilla Client still not support it? Is that correct? If it still not supported, can anyone suggest a way for me how I can easily and automatically check the hash value for correctness after downloading to ensure that the files are 100% transmitted intact?

Thanks

[botg]

If you use secure protocols, such as FTP over TLS (FTPS) and SFTP, integrity protection is part of the protocol, no need for a separate hash check to protect against corrupted transfers.

[eddie1]

Hi Botg,

Thanks for your opinion, but even if we use FTPS, there is no guarantee that files are 100% transmitted intact without problem, right?
Please see the picture (https://drive.google.com/drive/folders/ ... drive_link), in the past week, we have consistently encountered this problem, the file can be opened and read, so we didn’t know that there was a problem with the image file, so we printed…. huge loss.

So, we are wondering if using SHA-256 or even SHA3-512 would be effective in preventing such errors?

[boco]

The problem is that neither FTP nor SFTP do provide any native support for any hash-/checksum-related operations. The HASH command that could be enabled in the old 0.9.x Server was an experimental feature and a draft for an RFC was underway ("draft-bryan-ftpext-hash-02 - File Transfer Protocol HASH Command for Cryptographic Hashes"). Sadly, it never got anywhere. The feature is no longer present in any 1.x Server.
There are individual custom solutions of some servers (CRC, MD5, SHA, XCRC, XMD5, XSHA), but nothing official. FileZilla does not support feature fragmentation and thus only includes official features.

FTPS and SFTP protect the data at protocol level. However, the transfer can still break and send truncated files. Another issue could be if the files are received OK, but then written to the disk with errors (e. g. bad/weak disk sectors or defect RAM). That's why FileZilla also does not support any "Delete after transfer" features.
Personally, I create hashes of the entire tree before transferring, and verify them after transfer. However, you need shell access to both source and target for this.

[eddie1]

Hi Boco,

Thanks for your prompt response.

We have now communicated with the client and requested that they generate hash values (SHA3-512) for the files before transferring them. This will allow us to perform verification after the transfer and hopefully prevent such issues from happening again.

[botg]

The proposed way to use the HASH command wouldn't even detect errors that happen when reading from, or writing to disk. Following a transfer, all HASH would do is to re-hash the data still cached in RAM. It also wouldn't discover files getting corrupted at rest.

As boco wrote, what you need is separate files with the hashes, or even better yet, cryptographic signatures.

[botg]

As for preventing the most common causes for random corruption in the first place, to the degree it is possible: Secure protocols are guarding the wire, ECC RAM protects main memory, and checksummed filesystem such as ZFS or Btrfs protect data at rest.