FileZilla Forums

While striving for the highest possible security level is a good thing, I am not comfortable with the dogmatic and rather impolite approach to solve/not solve the problem for many users.

Fact is: Many FileZilla users with the ECONNABORTED issue cannot influence changes on the server software and cannot change the server or the provider or organizational structures because of this issue in just a couple of days.

So, the discussion is IMHO not about if it is a security risk or not, or how severe it is. It is about finding an adequate and sufficiently secure solution for an imperfect world.

As others here, I see only two alternatives: reinstalling an older FileZilla version or switching to a different FTP client.

To avoid that, I suggest including a warning dialog if FileZilla detects a non-standard behaviour on the server side to let the user decide if he wants to continue or quit the session. Or including a parameter in the server manager that allows to override the FileZilla standard behaviour on a per-server basis.

The 3.1.2-rc1 feature list looks interesting, but unless there is a workaround for SSL/TLS incompatible servers, it does not make sense for me to test and use newer FileZilla releases.

botg wrote:1GB limitation? Again the server's at fault.

That very well may be! But luckily all other FTP clients I've used besides FileZilla have managed to figure out ways to get around this issue....

I like to use filezilla. But these bug is very frustrating for me. (Downgrade is only one what I did to resolve this).

I can not change FTP settings and my webhosting didn't changed a rules.

I speak for patch this.

yucikala wrote:I speak for patch this.

Of course it must be patched, I agree. It must be patched in the FTP server.

Some of the most popular servers are already patched. But then again, the typical webhost is running their servers with aged software that has witnessed more moons than a man can count with both his hands. It's about time some ISPs get burned so that they'll install updates more frequently. A good administrator checks for new versions daily.

I just had this problem on my own server which is the newest FileZilla. Can anyone help?

Volderbeek wrote:I just had this problem on my own server which is the newest FileZilla. Can anyone help?

Do you really use 0.9.27? It included a fix for that problem.

I can not patch server. Only what i can is:
a) downgrade Filezilla
or
b) use other SW

I think that (and one user write it also) if you are new and try to use FileZilla - this bug say to user go away.... The idea with ask user "do you want these risk" is much much better...

You said it's your own server, why you can't update to 0.9.27 then? 0.9.27 is already fixed, no need to patch yourself.

Part of 0.9.27 changelog:

boco wrote:

Volderbeek wrote:I just had this problem on my own server which is the newest FileZilla. Can anyone help?

Do you really use 0.9.27? It included a fix for that problem.

I do. I just downloaded and set it up a week ago. It worked fine with TLS until the other day when that started to happen. How can I fix it on the server side?

Ah, nevermind. Making a new certificate seems to have fixed it. I'll be back if it happens again though.

Hello, I agree that the server should do a tlsshutdown causing the close_notify to flow when closing a secure connection. However, many FTP servers do not issue the tlsshutdown. Furthermore, neither did FileZilla until the latest release. Thus, this change has broke connections that previously worked. I respect the fact that you are now following RFC2246, but I must say that this should have definitely been implemented through a configuration option to avoid breaking existing, working, FTP servers.

Thanks,
Barry

You got the sourcecode.

I guess I am not aware how the changes actually get put into Filezilla?
Thanks, Barry

Thank you for the lists of broken servers and proper servers.

Wondering if there is a base of experience with Pure-FTPd. What versions behave properly? Which are broken?

Many thanks!