invalid GnuTLS ciphers string for GnuTLS < 2.11.5

[James Ralston]

FileZilla supports GnuTLS versions 2.8.3 and later.

However, in src/engine/tlssocket.cpp, the following code appears:

#if GNUTLS_VERSION_NUMBER >= 0x030100
char const ciphers[] = "SECURE256:+SECURE128:+ARCFOUR-128:-3DES-CBC:-MD5:+SIGN-ALL:-SIGN-RSA-MD5:+CTYPE-X509:-CTYPE-OPENPGP";
#else
// Versions before 3.1.0 cannot combine level keywords
char const ciphers[] = "SECURE128:+ARCFOUR-128:-3DES-CBC:-MD5:+SIGN-ALL:-SIGN-RSA-MD5:+CTYPE-X509:-CTYPE-OPENPGP";
#endif

But this is wrong, because SIGN-ALL wasn't added to GnuTLS until version 2.11.5. From the GnuTLS ​NEWS file:

* Version 2.11.5 (released 2010-12-01)

** libgnutls: Reverted default behavior for verification and
introduced GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT. Thus by default
V1 trusted CAs are allowed, unless the new flag is specified.

** libgnutls: Correctly add leading zero to PKCS #8 encoded DSA key.
Reported by Jeffrey Walton.

** libgnutls: Added SIGN-ALL, CTYPE-ALL, COMP-ALL, and VERS-TLS-ALL
as priority strings. Those allow to set all the supported algorithms
at once.

Because of this bug, FTPS support is broken on Red Hat Enterprise Linux 6, which is a very common Linux distribution.

I created the attached patch. I've tested the patch locally, and verified that FileZilla can now properly make TLS-enabled FTP connections on RHEL6. Could you please apply it?

One caveat: you should verify that my selection of signature algorithms is reasonable.

Thanks!

[James Ralston]

patch to correct FileZilla's ciphers string for GnuTLS < 2.11.5

[Tim Kosse]

Thanks for the patch.

As GnuTLS is as security library, I've instead opted to bump minimum required GnuTLS library version to 3.1.12 and to remove support for outdated GnuTLS versions.

[James Ralston]

Hmmm. I think there are some problems with your approach.

First, requiring GnuTLS ≥ 3.1.12 means that FileZilla will not compile on many popular Linux distributions, especially ones used in enterprise environments. Here's what GnuTLS versions various Linux distributions ship with:

RHEL5: GnuTLS 1.4.1

SUSE11SP3: GnuTLS 2.4.1

RHEL6: GnuTLS 2.8.5

The only enterprise Linux distribution that meets your requirement is RHEL7, which hasn't been released yet!

Second, there is not necessarily a correlation between the "newness" of a library and its security robustness. In fact, the opposite is often true: the more recent the version is, the more likely it is that it contains bugs that haven't yet been discovered.

For example, RHEL5 was not vulnerable to the Heartbleed bug with OpenSSL, because the RHEL5 version of OpenSSL (0.9.8e) did not support the TLS heartbeat extension.

Third, even if your reasoning is correct (that the more recent the library, the better the security), it's irrelevant, because you have no power to force Linux distributions to upgrade their GnuTLS library versions. If you keep your GnuTLS ≥ 3.1.12 requirement, here is what will happen:

1. When the people who package FileZilla for various Linux distributions discover that the latest FileZilla no longer compiles, they will respond by packaging the last version that still compiles instead. You will keep getting bug reports for bugs that you have already fixed in later versions... which many/most people aren't using because they won't compile.

2. Eventually, if the packagers receive enough complaints, they will simply stop packaging FileZilla entirely.

Would you please reconsider, and just use my patch? Limiting the GnuTLS library versions that FileZilla supports provides no benefit; it just makes everyone's lives more difficult. And it reduces the audience of people who can use FileZilla.

[Tim Kosse]

You want to compile a version of FileZilla not yet in your distributions package repository. This new version requires another library also not yet in your distributions package repository. Simply compile the dependency as well!

[James Ralston]

Let me be clear: *we can't use your patch*.

Red Hat will not upgrade the version of GnuTLS in either RHEL5 or RHEL6, which is where we're trying to use FileZilla. Because of this, we can't compile any version of FileZilla with your patch on RHEL5 or RHEL6.

We need a patch that will fix the bug *and* still permit compilation against GnuTLS 1.4.1 and 2.8.5. That is what my patch does.

If you approve of this patch, please say "well, if you can't upgrade to a more recent version of FileZilla because you're stuck with old versions of GnuTLS, your patch is the next best way to solve the problem". That way, I can point the EPEL maintainer of FileZilla at this thread, and say, "please incorporate this patch, because it fixes the TLS bug, and upstream approves of it".

If you don't approve of my patch, please tell me what's wrong with it, and I will rework it.

But please don't tell us to just use a more recent version of FileZilla that has your patch instead. We *can't*. We *must* be able to compile against GnuTLS 1.4.1 and 2.8.5.

Thank you.

[Tim Kosse]

Why do you *must* be able to compile against an old GnuTLS version?

Instead, why not simply compile a newer version of GnuTLS alongside FileZilla?

[James Ralston]

Building against a local copy of a system library is undesirable, because if bugs and/or security vulnerabilities are discovered and fixed in the system library, those vulnerabilities will still exist in the local copy of the library that the application was built with.

So, for example, if a critical security exploit were discovered in GnuTLS, and Red Hat released a GnuTLS package update for RHEL that fixed the exploit, if FileZilla had been built against a local copy of GnuTLS, FileZilla would remain vulnerable. Even worse, the FileZilla maintainer for Fedora and/or RHEL might not remember that FileZilla was linked against a local copy of GnuTLS, so the critical exploit might persist for months or even years.

In order to ensure that critical bugs and security vulnerabilities in a library do not remain hidden on a system after the main system library has been patched, the Fedora packaging guidelines *prohibit* building against a local copy of a system library:

​http://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_libraries

For the same reason, the packaging guidelines not only prohibit static linking against a system library, but prohibit even providing static libraries to link against at all:

​http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries
​http://fedoraproject.org/wiki/Packaging:Guidelines#Statically_Linking_Executables

(Red Hat largely follows the Fedora packaging guidelines for RHEL packages. So do the EPEL maintainers.)

So, this is why we cannot compile/link FileZilla against a newer, local version of GnuTLS. For Fedora, for RHEL, and likely other Linux distributions, you *must* link against the system-provided GnuTLS library. Even if the system GnuTLS library is an old version.

Again: is my patch reasonable? Is there a better way to maintain compatibility with GnuTLS 1.4.1, as well as more recent versions?

[Tim Kosse]

FileZilla now requires GnuTLS 3.4.0 or greater.