FileZilla 3 development diary

[boco]

Remove all fallbacks. But keep the option where the user has to explicitly define the Encoding used. Unfortunately, there are still non-UTF-8 embedded devices that are used for backups. Without any option to at least specify the character set used to speak to old servers, FileZilla would have to offer support for translation tables (small files that accompany non-conform files, which contain the correct name of the file, while the filename would be trimmed to be 7bit-ASCII-conform).

I still do use such a server (old NAS) for backups and I just cannot rename hundreds of files before backing up, and back when restoring.

[botg]

It's this custom character set fallback that's the most problematic.

[boco]

Yep. It's an expert feature and requires expert knowledge. Remove it from the GUI (but leave in the XML files).

At least, keep the fallback to the main codepage the user uses on the OS.


Edit: My biggest grief is not the transfer, my biggest grief is that you're not even able to remove such files from the server. A lot of stray files that can only be removed with other FTP software...

[botg]

The GUI isn't the problem. It's converting a symbolic name, e.g. the string "Windows-1252" to a numerical codepage identifier. Windows has no API for it.

At least, keep the fallback to the main codepage the user uses on the OS.

That's UTF-8 on most platforms. "Hmm, UTF-8 fails, let's try UTF-8 instead".

[boco]

There's also a default codepage for non-Unicode Apps. Mostly Western /ISO8859-1.

[botg]

Only on one platform, but not the many others. It's a mess.

[botg]

SWEET32: Why it neither affects FileZilla nor FileZilla Server.

When using FTP over TLS, neither FileZilla nor FileZilla Server support any ciphers with a 64bit block size.

What's more, FTP over TLS, by virtue of using separate control and data connections, makes the attack a lot more difficult even if such ciphers were in use: Essentially an attacker would need to trick the client into processing huge, specifically crafted directories with millions if not billions of files to generate enough traffic on the control connection.


Now to SFTP: There FileZilla still uses ciphers with 64bit block size. However it is not a problem due to the aggressive default rekeying policy used by PuTTY, upon which FileZilla builds SFTP support: Every 1GB of traffic, or every hour, whatever comes first, the connection is rekeyed.

[botg]

Here's a little preview of what is coming soon:

Code: Select all

auto salt = get_random(private_key::salt_size);
auto priv = private_key::from_password("abcdetopsecret", salt);
auto pub = priv.pubkey();

std::string plaintext = "this is plaintext";
auto ciphertext = encrypt(plaintext, pub);

auto plaintext_decrypted = decrypt(ciphertext, priv);
assert(plaintext == plaintext_decrypted);

auto ciphertext2 = encrypt(plaintext, pub);
assert(ciphertext != ciphertext2);
auto plaintext_decrypted2 = decrypt(ciphertext2, priv);
assert(plaintext == plaintext_decrypted2);

If you need a further hint, it's something completely useless.

[boco]

Encryption of passwords in the XML files?

[botg]

Yes. It'll be extremely secure password encryption.

Considering most users run Windows, its like a vault door on a tent made of toilet paper during a hailstorm. But hey, the door looks cool and isn't that what counts?

[boco]

For the average user, feeling secure is more important than being secure. Just ease of mind.

Shouldn't be long before the "FileZilla encrypts passwords but they were stolen, why???" posts start.

[botg]

Same reason they would have been stolen were they unencrypted: Malware on user's computer.

Only difference is that I can then feel smug about it. Feel-good security works both ways

[botg]

FileZilla 3.26.0-rc1 has been released with support for encrypted passwords protected by a master password. This post explains how it works:

Threat model

Attacker category A:

• A passive attacker that can merely read all files stored on the user's computer.

Attacker category B:

• Passive attackers that can read active program memory
• Active attackers that can modify files
• Passive attackers monitoring input devices
• If user opts to use plaintext protocols: Passive attackers monitoring network traffic

Note that it is theoretically impossible to protect against attackers of category B unless expensive special-purpose hardware is used.

The master password functionality has been designed to protect the user's passwords against attacker category A. It does not and cannot protect against attackers of category B. Incidentally, this functionality is indistinguishable from not storing passwords at all from a security perspective.

Setup

When configuring a master password (P_master), a random 32 byte salt (S_m) is generated. From the password and the salt, a X25519 private key (M_priv) is generated using PBKDF2_HMAC_SHA256:
M_priv' = PBKDF2_HMAC_SHA256(P_master, S_m, 32, 100000)

From M_priv', M_priv is obtained by clearing the three least significant bits of the first byte and the most significant bit of the last byte and by setting the second most significant bit of the last byte to 1.

The corresponding public key (M_pub) is:
M_pub = X25519(M_priv, 9)

M_pub as well as S_m are remembered for later use.

Encryption

When saving a password (P), first a random 32 byte salt (S_e) is generated as well as a random ephemeral X25519 private key (E_priv) and its public counterpart (E_pub). Using Elliptic-Curve Diffie Hellman, a shared secret (R) is derived:
R = X25519(E_priv, M_pub)

From R, M_pub, E_pub, S_e and S_m, both an AES key (K) and a nonce (IV) are derived:
K = SHA256(S_e || 0 || S || E_pub || M_pub || S_m)
IV = SHA256(S_e || 1 || S || E_pub || M_pub || S_m)

The password is then encrypted with AES256-CTR and stored together with E_pub and S_e:

C = E_pub || S_e || AES256-CTR(K, IV, P)

Decryption

When decrypting a password (C), it is first split into E_pub, S_e and C1 such that C = E_pub || S_e || C1

Next, using P_master and the stored S_m, M_priv is calculated as during setup.

Using ECDH, the shared secret R is recovered:
R = X25519(M_priv, E_pub)

K and IV are calculated as before and the password decrypted:

P = AES256-CTR(K, IV, C1)

Literature

RFC 7748 for X25519 and its application for ECDH
RFC 2898 for PBKDF2
Wikipedia article about AES
Wikipedia article about Counter mode

[ariel]

FileZilla 3.26.0-rc1 has been released with support for encrypted passwords protected by a master password. This post explains how it works:

Just wanted to chime in and say THANK YOU for this.

I had created this feature request 9 years ago

https://trac.filezilla-project.org/tick ... comment:64

I'll close it if I can

...and I recall many had requested this same feature before me. It was a different world back then.
Who would have thought that the linux desktop would have go as far as it has today. I digress.

Thanks and keep it up as always.

[botg]

I'm glad you like a feature that doesn't even increase security.