FileZilla Forums

My question was more for original poster xeon to see if he has figured out a workaround.


botg/boco,

I could provide you ftp access to our test server where this is consistently reproducible. Let me know if that works for you.

That would be @botg, then, as I'm not a developer.

sachintheonly wrote:My question was more for original poster xeon to see if he has figured out a workaround.


botg/boco,

I could provide you ftp access to our test server where this is consistently reproducible. Let me know if that works for you.

Unfortunately, I don't see any way to work around it on FileZilla.

I have a feeling it's related to GnuTLS, but I have no evidence to support that other than the fact that they seem to break session reuse for FileZilla quite often.

It's not a huge deal since the transfer automatically starts up again and resumes where it left off.

I did test WinSCP and lftp however, and neither of them had this problem, they're using OpenSSL though.

Can you please send me login credentials to a server where you're experience the problem?

botg,

Can you please give me your email address where I could send the temporary credentials?

It's on the Contact page.

I have sent the details to the contact email address.

Good news, I managed to reproduce it on the test system. It appears that GnuTLS' function gnutls_session_set_data fails modifies the internal state of the session upon failure [*]. My solution to the problem is to throw away the session and to reinitialize it when gnutls_session_set_data fails. I still need an hour or so to test if the fix really works.


[*] It can be argued that leaving an object in an inconsistent state after a failed method call is a case of bad software design.

The issue seems to have gotten worse with version 3.6.0-beta1.

After 1 hour, instead of the next transfer just failing once and automatically resuming, it actually errors out the remainder of the queue with this:

03:36:41 Response: 522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page
03:36:41 Error: File transfer failed

Also, on an unrelated note, I noticed that AES in CBC mode seems to be preferred over AES in GCM mode, seems a bit backwards.

Not much we can do here. The server requires session reuse, yet the very same server poses a 1 hour expiration limit on the session lifetime.

This problem cannot be fixed client-side, only worked around with extreme effort

botg wrote:Not much we can do here. The server requires session reuse, yet the very same server poses a 1 hour expiration limit on the session lifetime.

This problem cannot be fixed client-side, only worked around with extreme effort

Have you looked into vsftpd to verify that this is definitely the case?

Taking a quick look at their source code, it looks like he set INT_MAX for the session expiration, which shows as about 68 years.

I also get no errors using WinSCP, lftp or cURL for over an hour using the same session.

Also, did you find out why AES-CBC is being preferring over AES-GCM?


Thanks

Taking a quick look at their source code, it looks like he set INT_MAX for the session expiration, which shows as about 68 years.

Indeed, I've been mistaken.

Upon closer inspection, it turns that GnuTLS itself is imposing a client-side limit of one hour, controlled through the gnutls_db_set_cache_expiration function. Unfortunately the documentation doesn't mention that it actually controls the session lifetime itself, not just the caching of the session. At least with FTP, the session doesn't need to be cached as its an intrinsic part of the control connection that stays open.

xeon wrote:Also, did you find out why AES-CBC is being preferring over AES-GCM?

No, not yet.

Please try the latest build from http://filezilla-project.org/nightly.php

botg wrote:Please try the latest build from http://filezilla-project.org/nightly.php

That appears to have fixed it.

Also, I noticed you added a cipher tool to the debug menu, odd how all the predefined cipher-spec strings for GnuTLS all seem to prefer CBC mode over GCM.

Hopefully something can be done about that, GCM mode is far superior as it removes all the problems of AES-CBC, and GCM itself is hardware accelerated on newer chips along with AES, making it very fast.

Thanks

Hello,

Are there any plans to prefer AES GCM over CBC?

It appears RC1 is still preferring CBC mode.


Thanks