Connection failures if server is not configured properly for FTP over TLS

[texmurph]

Something is amiss with the latest release 3.10.0 of FileZilla.
I have always downloaded and installed the latest version.
Today when I did that, FileZilla stopped working. Can you let me know
the fix, or point me to somewhere that I can download the previous version?
I am still running the previous version on my backup laptop, and FileZilla
works on that one. Server has not changed. Only FileZilla has changed, and this is the result:

Status: Resolving address of www.k9tag.com
Status: Connecting to 23.246.197.178:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering Passive Mode (23,246,197,178,63,49)
Command: MLSD
Error: Connection timed out
Error: Failed to retrieve directory listing

[texmurph]

I found the older version 3.9.0.6 and installed in place of 3.10.0. I can now connect to my server as always, no problemo.

FileZilla 3.9.0.6 works.
FileZilla 3.10.0 is broken for now as far as I can tell.
Please let me know when it is fixed and I will be happy to try again. Thanks!

[Lloyd DeKay]

Yep, messed up pretty badly. If you don't have a copy, you can get 3.9.0.6 at ​http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.9.0.6/
I just reinstalled that version and everything is working again.

WTF... no way to recall the update notices???

[Lunarion]

Downgraded to 3.9.0.6, works like a charm now.

(Windows 8.1 x64)

[Rebecca]

Not sure if this is the best place for it, but here's my results on 3.10.0
---
I can connect to a vsftpd server, no problem, but I cannot connect to any of my servers running WHM.

Status: Connecting to <IP>...
Status: Connection established, waiting for welcome message...
Status: Insecure server, it does not support FTP over TLS.
Status: Connected
Status: Retrieving directory listing...
Status: Directory listing of "/home/10552058" successful
Response: 421 Timeout. (<= inactive timeout, no issues)
Error: Connection closed by server

---

Status: Resolving address of <server15, it is running outdated software>
Status: Connecting to <IP>...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Connected
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: MLSD
Error: Connection timed out
Error: Failed to retrieve directory listing

---

Status: Resolving address of <server20, this one is up to date>
Status: Connecting to <IP>...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Connected
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: MLSD
Error: The data connection could not be established: ETIMEDOUT - Connection attempt timed out
Error: Connection timed out
Error: Failed to retrieve directory listing

[Tim Kosse]

Your server is not properly configured for FTP over TLS. Contact your server administrator or server hosting provider for assistance so that the server can be fixed.

[MrJ]

Replying to ldekay:

Yep, messed up pretty badly. If you don't have a copy, you can get 3.9.0.6 at ​http://sourceforge.net/projects/filezilla/files/FileZilla_Client/3.9.0.6/
I just reinstalled that version and everything is working again.

WTF... no way to recall the update notices???

Awesome, thank you so much! I had the same problem after letting it update on Sunday and submitted a ticket (no idea where it is and received no reply), but installing the previous version 3.9.0.6 has me back in action. I think the developers don't believe us all that their latest version is the problem because we made no changes other than installing the latest version.

[Rebecca]

Replying to codesquid:

Your server is not properly configured for FTP over TLS. Contact your server administrator or server hosting provider for assistance so that the server can be fixed.

It's not supposed to have TLS enabled. The server is a test environment, and gets re installed every week or two when I screw something up and can't figure out what I did to break it. Just thought the results could help the developers figure out what they screwed up with 3.10.0

[JohnM]

Also downgraded to 3.9.0.6 to fix the issue. There is no way every major hosting company's server is configured wrongly. This issue is clearly a filezille one.

[Tim Kosse]

Downgrading worked around the issue, it didn't fix the issue. To fix the issue the server needs to be fixed.

[JohnM]

Exactly...downgrade worked around, until the update can be fixed. There should be no need to configure the server one way or another for this piece of software to work. It never has in the past. The update clearly broke something. When some thing goes from plug and to play to doesn't work anymore something is wrong.

[Tim Kosse]

Your server is not properly configured for FTP over TLS. Contact your server administrator or server hosting provider for assistance so that the server can be fixed.

[JohnM]

How was it working perfectly before this update and now is not? Why should something have to change on my server? Why should it not work properly as before?

[Tim Kosse]

Before you probably weren't using FTP over TLS. These days you are, because the server says it supports it, when in fact it doesn't.

[Lloyd DeKay]

Apparently Filezilla is now requiring the use of TLS for FTP connections. Yes, it is more secure, but to FORCE use of a standard that obviously is not standard in it's user community (just check out the ever-increasing list of 3.10.0 complaints) is the epitome of arrogance. Few users have the ability to force their hosts to implement TLS, but because Filezilla feels it is the right way to go... IT MUST BE DONE!!!

Unfortunately for users of this fine tool, that degree of hubris generally leads to a massive fall from grace. Do you really want to be known as TLS-Nazis? When we install an update that doesn't work and there's no explanation, or even a suggestion provided at the point of breakdown, you've likely disenchanted your users. When you take an arrogant defensive stance you've definitely disengaged your fans. What a shame.

[JohnM]

My sentiment exactly. Even worse is to play passive-aggressive and not answer a pointed question directly with an true explanation. I have over 200 hosting account in my FTP Client. Do you really feel I got time to go ask 200 hosting companies if they can do this for me?

[Tim Kosse]

@ldekay: Stick to the facts please.

FTP over TLS is not required. FileZilla asks the server whether it supports FTP over TLS. If it does, then FTP over TLS is used.

If your server or any associated firewall or NAT router isn't configured properly for FTP over TLS, then it needs to be fixed.

[JohnM]

Actually even that answer was CRYPTIC at best. But you finally alluded to something real. So the fact is FTP over TLS is not required.

Of course you could have explained exactly what was really done which was re-assign <Protocol>0</Protocol>, which was formerly the Encryption option "Use Plain FTP", to "Use Explicit FTP Over TLS If Available" and change the "Use Plain FTP" option to <Protocol>6</Protocol>. Not sure this was really a forthright way to do this.

So here is the fix if you are OK using the "Use Plain FTP (insecure)" option. Since it is supposedly insecure I will preface this will do you own due diligence and use at your own risk:

Go to your sitemanager.xml file and run a search and replace on <Protocol>0</Protocol> and set it to <Protocol>6</Protocol> and things should go nicely back to normal.

[Tim Kosse]

From the version history: https://filezilla-project.org/versions.php#3.10.0-beta1

FTP over TLS is now used by default if the server supports it. Use of plain FTP can be enforced for a server in the Site Manager

For FTP over TLS to work, not only does the FTP daemon need support it, all firewalls and NAT routers the server are behind need to properly configured as well.

You can use ​https://ftptest.net/ to check your server's configuration.

[Filipe Rafael]

Replying to codesquid:

Downgrading worked around the issue, it didn't fix the issue. To fix the issue the server needs to be fixed.

---

Your stupid the old version was working properly, how can the old version is working and this "shit" does not work. So there are many people with the same problem, because the problem is the NEW VERSION.

[Tim Kosse]

Your server or a firewall in front of it isn't correctly configured for FTP over TLS. Contact your server administrator or server hosting provider for assistance so that the server configuration can be fixed.

[Filipe Rafael]

I have been searching and the problem is neither the server nor the firewall. The problem found even in FileZilla, moreover in his options. Here is a print what to select an FTP without SSL

---

---

[Dennis]

So when my Host says, "FTP over TLS is supported", and FileZilla says, "it is not", then we are in the middle with each blaming the other. What hope have we got?

Sounds like we just set Plain FTP (insecure) and forget all this. Nothing on my website that anyone would want to grab or hack!

[Tim Kosse]

Please tell your host to contact me directly via email. I'm more than happy to explain in depths what is wrong.

[Dennis]

Email just sent.

Good Morning,

I use FileZilla to upload my files to my website hosted by Just Host.

Until recently this has been a very smooth arrangement. With a recent 'upgrade' of FileZilla, version 3.10.0.2 a fatal error in connection occurs.

Searching for a solution, I have come across this discussion:-

FileZilla Version 3.10.0.2 sets Encryption as "Use explicit FTP over TLS if available" as the default.
Filezilla says if this does not work then the Host Server is incorrectly configured - contact your Host.
Discussion is here:-

​http://trac.filezilla-project.org/ticket/9995#comment:24

As you see, FileZilla wishes to discuss what needs to be done.
As requested I am asking you to please contact FileZilla to understand why you need to change your Server settings.

Kind regards

[LexLechz]

Cannot believe this issue is rejected, because also people reporting their issue in ​http://trac.filezilla-project.org/ticket/10121 are affected as well.

I've contacted the administrator of one of my affected sites and he recommended the use of "smartFTP" (payed software with trial-version). Administrators are most likely NOT interested to hassle with not working client-software and are looking for a quick solution that allows their customers to work!

So Windows FTP works, smartFTP works: But FileZilla does not work and will never work again in affected environments? No workaround for problems in well known incorrect server-configurations?

[Tim Kosse]

Neither of those other clients uses FTP over TLS. If you were to tell SmartFTP to use FTP over TLS it will fail too on your server.

Since the server says it supports FTP over TLS, FileZilla expects it to be configured correctly.

[LexLechz]

Ah, now we come to the point (which was not clear to me in the earlier comments):

The problem with the affected servers is that FTP over TLS is improperly configured. Because they are reporting to support TLS FileZilla attempts to use it - and fails.

I've not changed my FTP configuration and the FileZilla default encryption is "Use explicit FTP over TLS if available". This does no longer work with some servers.

However THERE IS A WORKAROUND, so people can update to the most recent FileZilla version:

In the site-manager select "Only use plain FTP (insecure)" as "Encryption" option. Even if it's truly insecure, it's the same connection type that was used in earlier FileZilla versions and is the only type, effectively supported by the server.
Who want (need) to use a secure connection has to contact the server administrator.

So the status remains: closed, won't/can't fix -and- workaround available :-)

[JohnM]

Replying to LexLechz:

Also here is a global fix if you manager multiple websites in the filezilla file site manager and want to set this all at once. In my case I manager several hundred websites and could not site and do this site by site:

So here is the fix if you are OK using the "Use Plain FTP (insecure)" option. Since it is supposedly "insecure" I will preface this by saying do you own due diligence and use at your own risk:

Go to your sitemanager.xml file and run a search and replace on <Protocol>0</Protocol> and set it to <Protocol>6</Protocol> and things should go nicely back to normal.

[Dennis]

OK, I contacted "Just Host" at this address support@…

This is their reply:-
Hello,

Thank you for contacting our Technical support department. We apologize for the inconvenience that you have experienced.

Filezilla is a third party application. The upgrade process that you have mentioned has been performed from their end. We are not able to contact them regarding this issue.

If you need further assistance with this matter, please feel free to reply to this email. But before we can proceed we need you to validate ownership of the account by giving us ONLY ONE of the following:

• The last four characters of the current password on your account.
• The last four digits of the credit card used for the most recent web hosting payment.

If you have other issues we can assist you with, please open a new ticket.

Help us improve our support by answering a quick survey: ​http://survey.justhost.com/s3/Zm7d25G6HJ

Thank you,

Keerthi
Level I Tech Support Engineer
Justhost.com
888.755.7585

Find answers immediately using our online help resources:
Knowledgebase: ​https://www.justhost.com/cgi/help
Tutorials: ​http://www.justhost.com/tutorials

---

So as I said before, the users of FileZilla are the bunnies in the middle. All we can do is revert to Plain FTP.

I can see FileZilla will lose a lot of users as it is not been made clear what to do to work around this problem. They will just see a program that DOES NOT WORK and go elsewhere for a solution to their FTP uploading solution. Pity, FileZilla was a fine program.

[Lloyd DeKay]

Is it possible for codesquid (or anyone else) to create a document outlining the "proper" steps to set up TLS in the server environment? If that is not too varied, I'm sure this would be helpful to those who're self-hosted, and it might be a useful reference for the techs at various hosting services.

Note: GoDaddy and FatCow accounts apparently pass the test, but JustHost, BlueHost, DreamHost don't. The xxxxHost group are all affiliated, so a guide to "proper" implementation could help several at once.

[Tim Kosse]

See ​https://ftptest.net/Help for detailed instructions how servers, firewalls and NAT routers need to be configured.

​https://ftptest.net/ can also be used to test the server configuration.

@scorpion61: You should get a different hosting provider. No serious hoster would ever ask you for your password (even if partial) via email.

[Ken T]

it would seem that others are having the same problem that I am when trying to connect to the SAME sites as we connected to with previous versions of Filezilla. Your obscure /supercilious answers are irritating in the least. How can it not be the problem of this version when nothing else has changed.

Reminds me of the early days in the 90's when providers spent ALL their time pointing at someone else when they were clearly the problem

[Tim Kosse]

Please don't reopen this issue. It is not a bug in FileZilla.

[tom]

SOLVED!
I had this issue with Liquid Web as my hosting provider. After working through the problem with their helpful staff, he was able to figure out how to make this work. My server was setup for TLS however he had to enable passive mode connection. Once he did that everything started working. Not sure why this worked before but hey its working now.

Hope this helps others. I love that they actually solved the problem instead of giving the "third party software" excuse.

[Dennis]

@codesquid Have you contacted JustHost, I have given you the details, or you going to just sit on your hands and continue to blame the other guy?

It is FileZilla that is going to miss out here as with the present configuration and NO EXPLANATION to users on what might be happening unless they stumble on this site, you are going to lose users in droves. The Log messages tell you nothing.

This ticket MUST remain OPEN until YOU have SOLVED the issue appropriately.
Ask users for the hosts that are are in conflict with the present FileZilla settings and CONTACT them and RESOLVE it with THEM, Don't just leave it to present users to figure it out for themselves.

[tom]

Did you try my fix listed above?

[tom]

Also, in this guy's defense, this is probably not a bug, but a new feature request. Allow fallback to no TPS encrypted connections or some such. If the software is designed to work this way, then its working as intended. That doesn't mean the intention is good or bad, but it does mean its not a bug.

[spudgun007]

I'm looking at our Filezilla Server configurations and Both TLS and Passive mode is enabled, so that is not the issue for us.

It looks like this is very complex firewall issue to resolve, which is outside of my expertise. Connecting to it internally works, but not externally using the FTP address.

I am not going to ask for help here to fix our firewall issues. If we find out what the issue was I may post it if the team which deals with this sort of thing lets me know what it was to help others resolve it.

My biggest concern though is you have changed the interface and defaults and caused a lot of problems, and below I'll detail why they are an issue and why you need to resolve this.

I write this on behalf of all Support staff who have to deal with users who are not very computer literate and just wanted a simple client to connect to the FTP which for years Filezilla provided, who have just used the Quickconnect option after upgrading, thinking nothing would probably change, and suddenly finding that it's telling them it's timing out.

The message doesn't tell us that TLS isn't working or configured correctly, it makes to your average user believe the server is actually down and call screaming at you when they cannot get whatever they need from the server and is costing them money.

Others think the issue might be at their end, and may waste much time troubleshooting their own firewalls or connections.

Now that we know the issue, I am able to tell them to go to Site Manager and choose the insecure option and that allows them to get the data. However advising them of this work around upsets them even more because now we have told them to use an unsecure option which will make them even more paranoid and refuse to do anything you show as insecure, and how dare you even suggest they do something insecure.

Even when they are happy to do the work around, it's a major pain when you have to go to site manager and recreate each and every one of the hundreds of FTP logins and passwords you had already saved using the Quick Connect options that now no longer work and reconfigure them to use the Plain option, mostly having to retype a lot of very complex passwords.

Your response that this is your issue and you must get whoever is hosting the FTP server to now fix it to be able to use TLS is not a viable option for us.

The FTP server hosts hundreds of clients, and getting changes made to the firewalls requires change request which have to get many approvals and can take months to test and implement to ensure all customers it services can still use it. To simply suggest that it's your or your hosting provider's fault and expect them to fix it with a minor change is not a viable option for a large organisation.

The choice then becomes to roll back the version of filezilla, which is also very inconvenient for a large organisation who rolls out these changes company wide and has strict policies on what software can and cannot be allowed.

Most people who post here are probably IT literate who may be able to change whatever options you suggest they need to change in the firewall or the Filezilla service, but you don't have to deal with those who are not who all they see is connection timing out in filezilla client, or the more competent who can look on the server to see if the server is up who go to watch it in filezilla server interface which all it gives you is AUTH TLS, 234 Using authentication type TLS, then Disconnected, with no clue as to what went wrong.

This is the issue when you change defaults, and why everyone got so mad at facebook when they changed their defaults to make everything visible to everyone, because regular uses mostly don't change these defaults.

It is for these reasons that you need to either change it back to how it was so that Quickconnect can work for people, or if you really want to use TLS by default since it's more secure, automatically retry with the plain FTP if TLS fails and give a warning that TLS has issues so that at least they can still use it if the server or firewall is misconfigured, and you do not have to expect them to be experts and have to find things like this.

I'd prefer the first, because using TLS has other issues, such as if the certificate has expired or has an issue that it's unknown, it will also freak out users who never saw before a prompt asking them if they trust this certificate, which leads to more paranoia about security that is difficult to deal with.

I am therefore pleading on behalf of the thousands of IT support professionals to please fix this bug, or risk losing us all as users forever to either alternative FTP clients or your older versions which don't have this issue.

[Dennis]

@spudgun007

Well said ... I think you have summarized the situation extremely well.
Have a great day!

BTW: I live in Australia and my host is in the USA, so a phone call, including time difference is difficult and costly.

[spudgun007]

@scorpion61 I too am in Australia with a US hosting company, so I feel your pain as well since I'm in Australia it's one of the worst possible locations for an international conference call with it having to be either very early or very late.

I can understand that the change was well meaning to get it to automatically use a more secure option by default if it's available, under the assumption that they are doing them a favour by giving more security without needing to change anything.

But the assumption that all FTP servers in the world which have configured saying that they support TLS will all have this working perfectly and fail if it does not is far too optimistic and is a design failure in my opinion. If my organisation did a change like this in our software's defaults to our customers and it stopped working for them unless they made major changes to their server or firewalls because we assumed they'd all be configured perfectly, I am certain they would not be as forgiving.

If the customers requirement was that TLS was implemented for the FTP and must be used, then one could suggest that changes would have to be made to the servers or firewalls in order for it to be able to work. However, No such requirement has been made though for any of our clients who are using the normal FTP, and any who required higher security usually used something different such as SFTP or something else entirely such as AS2.

I completely understand that our firewall or whatever is causing our TLS configuration to not work ought to be fixed, but since no customer has yet required it, it will be a very hard sell to have either the very early or very late change control meeting, and get all the stakeholders to agree to whatever firewall change is necessary, I would be tempted to instead tell the customers to abandon Filezilla altogether and start using Windows Explorer as the FTP client if they did not have their sites configured in Site manager to easily change.

Those of us who have to deal with multinational companies change control processes where everything is locked down tight or have to deal with users who are not very computer literate and just want a simple application cannot easily make these changes suggested every time this ticket is closed.

I have loved using Filezilla for years, but I fear that this change will be its downfall for all the ordinary users who encounter this who will not be easily able to work around this.

I don't want to tell them to start using Windows Explorer instead, so please take this seriously and fix this bug in the next update to either reverse this or at least try TLS then try plain if it fails and log that TLS failed.

[Tim Kosse]

Please don't reopen this ticket, it is not a bug in FileZilla.

[Dennis]

@codesquid

As I thought, leave the poor users to sink or swim. Great.

Don't be surprised if FileZilla is abandoned by many users searching for a simple FTP client with an interested support person.

[spudgun007]

@codesquid

Are you actually reading what we are writing here explaining the impact of this change, or are you just closing each time on principal every time because you feel this isn't a bug?

If this is the case, I sympathise with you having worked in support where we had customers who would report something as a bug but it was just a design decision they did not agree with, or the problem was not with us but with them or their environment and the application would work perfectly if not for their environment issues.

However, when a third party would make a change which meant that our end did not work, and they would ask us to therefore change our program to work with them, we would refuse to spend our time and money to fix an issue which never happened or was necessary before they made the change.

From a non technical customer point of view, all they would say is Filzilla worked before your change, and now it does not. It's that simple.

You can argue it's not a bug all you want, and even say this is a feature request, and technically you may be correct. But you have to admit, this new Feature of yours to automatically use TLS if the server says it supports it is a flawed design potentially stopping millions of Filezilla users who can no longer use it due to an incorrectly configured FTP server which used to work for them.

If I treated one of our multinational customers like you have treated this ticket, and changed our application to add this extra security layer automatically that they did not ask for which broke the software and caused thousands of their users to no longer be able to use it, and instead of fixing the issue told them they would need to spend months without being able to use the software before they could fix whatever firewall issues are needed to get this to work with this new security setting, potentially costing them millions of dollars in lost revenue....
This would be the point where they'd be escalating to my manager or maybe even the CEO screaming.

In this scenario though, the customer knows what the problem is, and has enough power to pressure the manager to fix it. Most though will be not as computer literate users who would just say that it's not working, and if they were not in a powerful position to get a hosting server or company to make whatever changes are needed to get it to work with this new feature, or simply didn't know that this was actually the issue, they would just abandon it altogether.

Are you really this stubborn that you would risk Filezilla being dropped by everyone who experiences this issue, and have IT support professionals tell them they must no longer use Filezilla from now on if they want to keep using their FTP?

This is a change that could very well be the end of Filezilla as we know it.

In my experience, if something the client wants is indeed an enhancement request or a feature, we'd at least let them know of a new ticket number where this is a feature which would be considered for the next release, or better yet, tell them in which release or when this new feature will be added.

If you can do this and say that for a new ticket or feature request that you could make it so that it will try plain if TLS turns out not to be available in this scenario due to their firewall or ftp server configuration, then we would not need to keep going back and forth with people continually reopening this ticket, or with users continually creating duplicates when they cannot find this one.
As long as there will be people who get this error, and as long as there are FTP servers out there with misconfigured servers or firewalls, this ticket will likely be kept being opened by someone or new tickets created when this isn't found, until eventually everyone gives up on Filezilla altogether and it becomes a footnote in history.

Believe me, I know what you're going through, and I can understand why you keep closing it, and I've done what you've done in the past as well (hence the calls to the manager screaming reference).

What do you say codesquid, from one IT support professional to another, can you please find it in your heart to consider this, at least as a feature request that might be done in the next release if you really want to keep the TLS security if it's available?

[Rebecca]

@spudgun007

Thank you! I am support for a hosting company, and this has been hell trying to deal with it. It used to just work, and even the technologically incompetent customers could connect easily.

Changing firewall settings for a freaking FTP client has been on the bottom of the firewall admin's list, and this just gets more aggravating the more customers we have to talk through downgrading filezilla. Please make a change in the update that allows an automatic fallback to plain FTP if TLS fails. As it stands right now, we are looking for a comparable client to send our customers to instead.

[Tim Kosse]

Changing firewall settings for a freaking FTP client has been on the bottom of the firewall admin's list

I think you should reevaluate your priorities. Your server advertises FTP over TLS support while not actually supporting it.

This affects _all_ FTP clients using FTP over TLS.

this just gets more aggravating the more customers we have to talk through downgrading filezilla.

Instead of simply fixing the server, e.g. by reconfiguring the firewall or by disabling FTP over TLS, you go through the motions of telling users to use outdated software? You're making it orders of magnitude more difficult than it needs to be and even blame me for it instead.

[spudgun007]

@Codesquid,

You talk like as if it's that easy to change reconfigure an FTP server to stop using TLS, or just figure out the issue and fix it.

Working with large corporations making a change like this isn't something we can quickly and easily do, there are a lot of forms, approvals and testing that has to be done before a change like this can be done.

I'd love to just disable it and let it work with Filezilla once more, but I can't or I'll get fired.

I agree that it will affect all filezilla clients which try to use TLS. The difference is, the clients that we'd recommend hadn't changed their defaults to now require TLS if the server advertised it does this.

If our client had a requirement that it use TLS, and it did not, then we'd definitely have in the UAT environment it working with TLS before it would go to production.

However that was never a requirement, and it never had an issue until this upgrade. As far as the client is concerned, it's not working now.

It's not just me either, there's going to be thousands of sites where TLS doesn't work but they'll think that it's filezilla not working because it used to work.

Most users will not know to change it to plain in site manager, they'll simply abandon it, and this bug will keep being logged by different people who haven't found this, and keep being logged to your forums, because the error message doesn't make this clear.

This is a MAJOR design flaw.

If you want it to be secure I'd suggest that it try TLS, and if it fails then try Plain and warn the user that the server advertised TLS but it really did not so they can take appropriate action, or tick a box to ignore.

I am not blaming you for our server issues. I get that it ought to be fixed, but unless a multi million dollar client requires it, it's not going to happen.

I will happily change this from Bug to Feature request if you say it will be considered and likely be in a future release.

[Tim Kosse]

There already is a fallback: If the server rejects the AUTH TLS command, then plaintext FTP is being used. [*]

Falling back to plaintext FTP because of some connection failure after a successful handshake is a terrible idea though. Imagine a simple network outage; before you know it, your credentials are sent in clear over an untrusted connection.

An attacker could also force this: If he detects that TLS is used, he interrupts the connection and thus forces the plaintext fallback. These kind of downgrade attacks are a real problem, e.g. as with the POODLE attack.

As it is right now, the automatic fallback used by FileZilla is still vulnerable, though requires an attacker to be at least capable of modifying traffic. A more general fallback on the other hand would only require the far more simple capability of the attacker to withhold traffic.

In fact, loss of packets is so common, it would happen by accident all the time. A patient attacker would only need to passively listen to the connection, eventually a connection will fail by chance and a downgrade would be initiated.

[*] In future versions this automatic fallback will be tightened, the user will have to explicitly agree to the use of an insecure connection.

[spudgun007]

I can understand from a security point of view and encryption if the goal was either it be secure or not connect at all that you would prefer it be secure. I concede that automatically reversing it for TLS is a security issue if security was your prime concern and everything on your FTP it was critical that it be secure.

The problem is nobody asked for this to be defaulting to TLS security and demanded that it either be secure or not connect at all if TLS is said to be available and fails. And nobody is able to tell that this is the case with the error message you are giving without spending all day searching till you find something like this bug report.

As a hosting company, with FTP we accept that FTP is not as secure when they just want a way to be able to quickly and easily get some files that do not need that level of security, and advise the customer as much. If the customer wants more security we usually offer SFTP or site to site VPNs (and they pay more for this extra security).

FTP is there for simplicities sake, but by making this security as default via QuickConnect you have forced this upon us.

Using TLS or having all quickconnects use TLS by default should be an option, not the default. Forcibly changing all quickconnects to use TLS without our consent or even informing us of this is wrong, and is leading to all the confusion and chaos.

From a support point of view, if there is no change to the message and no indication for your QuickConnect users that it's the TLS that is the problem, then you are forever going to have this issue as long as there will be FTP servers which have configuration issues. This will always be posted in the forums, always be logged as a bug by people who don't realise the issue. As a support professional I strive to not only resolve issues, but ensure that they do not happen again, and you are not doing this by telling everyone they need to get everyone they connect to to fix the TLS or fix their own firewalls so they can use TLS.

The message one gets when it has failed in this scenario is not that TLS failed, but that it timed out. That is the biggest issue because there is no way an ordinary user would actually know if it is loss of packets here, and if they didn't know to try using Plain in the site manager, they would more likely just think that it's down, or worse that Filezilla now no longer works, and you will have lost that user forever.

In Site manager, we at least choose the TLS option and see that this now the default, Quickconnect users do not. QuickConnect should remain what you had before, which is Plain, which we know worked.

Quickconnect is for those who don't need to worry about all the extra security options and just want to connect using the least amount of configuration. This is what made Filezilla great, it was quick and easy for all users.

It is far superior to Windows Explorer in terms of FTP use, but it has now lost in terms of useability.

Most users always used filezilla the same as always using quickconnect, and would just upgrade to stop getting the message of a new version, usually knowing full well that nothing would likely change their experience and they probably would not use its new features.

However for those who had to connect to the TLS enabled servers with problems, you have changed it now, and for them it doesn't work if they don't know to recreate all their QuickConnect ones as Site Manager ones with Plain as the option.

There needs to be consent from the user to use TLS in Quickconnect, but you have changed it against our will. Now strange things are happening that never happened before with no explanation as to why. Even when TLS is working, certificates expire and now is confusing people with messages asking if you trust the certificate, causing more Chaos because they didn't know they were supposed to check for certificates now.

Even when they know to recreate it in site manager, having to recreate it with site manger is a major pain for some who don't remember the password that was saved to find it again.

You need to keep them as they were when they created them in the previous version, not force the new options upon them. By all means advise users when they create new Site manager connections that Plain is less secure than TLS and they ought to choose that instead, but don't make them use TLS if it never did before, and plain was working.

At least give them the option to change all Quickconnect connections to use TLS if available, but they need to be able to reverse it if it fails.

This design flaw I fear will be the end of Filezilla. Do you honestly think that a multinational company will change their firewall which hosts Thousands of employees over multiple countries, putting them at risk, getting lots of approvals and spending months testing, just for your new TLS default?

Or do you think ordinary users who see if fails now, but works in EVERY other FTP client in the world which defaults to plain works, will continue using Filezilla if they cannot find this is the issue and are unable to get the TLS fixed?

In software design, changing the defaults for users who have used these for all this time is one of the worst things you can do, because users are not going to usually look at them or know its been changed. This is why everyone was angry at Facebook for making default privacy viewable to everyone, and why they had to change it.

By all means, warn that it's using plain and they are vulnerable, but make it optional that they change the setting for all their saved Quickconnects and site managers, and make it reversible if it fails.

My suggestion would be to keep quickconnect as it was with Plain by default how it has always been, and prompt that users have the option to make them all more secure by choosing this option that will make all Quickconnects use TLS if available, or make the Use TLS if available a Quickconnect option as well that can be changed from Plain.

Right now there is no way to change the Quickconnects, and to me that's a major design flaw, and that is why this is a bug and not a feature request.

Changing to TLS by default was a feature request, but if this happened to our customer who would take months to change their firewalls just to accommodate our software, they would instead call this a failed change that was not tested properly for this scenario, and we would have to roll back or they would dump our software.

[spudgun007]

I just downloaded the latest version.

I noticed in the release notes the following:

3.10.1-rc1 (2015-01-24)

New features:
Fixed wording of some error messages when using FTP over TLS

I am not sure under what scenario there's a new error message, but it has not helped for our scenario because it's still telling us it timed out, so I'm not sure if I should log a bug for this supposed message which tells you it's a TLS problem not working if that was meant to satisfy my complaint.

Still get the following error

Status: Connection established, waiting for welcome message...
Response: 220 FileZilla Server version 0.9.41 beta Welcome to our FTP
Command: AUTH TLS
Response: 234 Using authentication type TLS
Status: Initializing TLS...
Error: Connection timed out
Error: Could not connect to server

And in Filezilla server we see

Connected, sending welcome message...
(010353)2/2/2015 23:05:26 PM - (not logged in) ()> 220 FileZilla Server version 0.9.41 beta Welcome to Our FTP
(010353)2/2/2015 23:05:26 PM - (not logged in) ()> AUTH TLS
(010353)2/2/2015 23:05:27 PM - (not logged in) ()> 234 Using authentication type TLS
(010353)2/2/2015 23:05:48 PM - (not logged in) ()> disconnected.

One thing we did find is we can get it to work if we use in Site Manager Require Implicit FTP over TLS, so it's not an issue with using TLS itself.

Our Hosting manager's theory is that it's due to the Firewall having stateful FTP packet inspection, because for stateful FTP inspection it will not be able to parse the encrypted traffic.

Hopefully this will help others who manage to find this issue and now have a way to resolve it other than reverting to using Windows Explorer or another FTP client that has not forced this upon all the users who use QuickConnect who don't want to reconfigure them all to use either Plain or Implicit TLS.

My complaint still stands, in that we still shouldn't have to change it. While I may be able to get our FTP server changed to remove this setting, who knows how many other's in the world have this setting who will potentially refuse to change it, or never know that this is the issue.

As I said before, very large organisations are not going just change this setting, this will take months of approvals, analysis, testing and security audits before it would be able to be changed if this would be required to allow Filezilla to work, assuming that the change request is actually approved.

Given that using Explicit TLS was not a security requirement and all the trouble it will be to change this, I'm afraid the change will be rejected, but at least hopefully this will help others if the powers that be decide not to fix this, or at least add a feature I suggested if they wish to continue this.

I'm currently evaluating WinSCP as a possible alternative to Filezilla. It even is importing my Filezilla Sitemanager ones into it, but unfortunately does not have the ability to import the QuickConnect ones that the majority of our users use, and is not as easy for them to use as the QuickConnect was since it defaults to SFTP and would require them to know to change it to FTP. However, at least when you choose FTP for the new connections, it's at least defaulting to the one it always had an not changing all the ones they were previously using.

This has been opened and reopened for 4 weeks now. I really hope that they can see how big an impact this is having and how much we don't want this to cause Filezilla to be abandoned, so please consider fixing this, or at least having a feature to be able to cater for this scenario if it's stateful packet inspection settings in the firewall that is the culprit.

[spudgun007]

There's been no update to this for 8 days I see without it being closed again.

I'm not sure if this means that it's being considered for the next release or if it's being ignored.

As I said, I believe the reason that the new default for the QuickConnects failing due to using the Explicit TLS if available is due to the FTP server's firewall using Stateful Packet inspection.

The Hosting manager will not remove that because it's a security risk.

They will also not remove the TLS option if it's not supported, because it does work for Implicit TLS which is a requirement for other clients.

I suspect there are many more servers out there with this same firewall configuration who have had Filezilla appear to stop working to all users because of this change to the default.

I can possibly try and get an exception for Stateful packet inspection for FTP traffic only to cater for Filezilla's new default, but given it can take months in the change control process, I'm not confident it will be approved when they could instead ignore Filezilla.

Hopefully this post will help those who are experiencing this who may be able to change their firewall easier that a large organisation can though.

I therefore urge you to either reverse this or give users notice that the default has changed and allow them to choose to change the QuickConnects, and have a way to reverse it if it has caused issues like now.

This way you don't have to keep replying to this in the Forums forever, though most I suspect won't find it either in the Forum or this ticket.

I feel this design decision to change the default should be classified as a bug because of the massive impact it has had, however I would be willing to change it to a feature request if we could get a confirmation that it will be considered and possibly done for a future release.

[spudgun007]

Still no reply? I hope that means Codesquid is considering this and not ignoring me.

An update for the situation for one client we support who did not have such a big long change control process who was using Stateful packet inspection was in Filezilla Server they decided to go to Filezilla Server Options, Select SSL/TLS settings and unticked Allow Explicit FTP over TLS.

With this unticked it still allowed the Implicit TLS and Stateful packed inspection, but when connecting it would instead say Insecure server, it does not support FTP over TLS.

I am still worried that this might cause concern for people using it who see this, but I suspect most will not notice.

I still maintain that it's a bad design and should be a bug, and you should not expect all FTP users and server providers to be able to figure this all out, and it would be nice to have a way to choose not to use this setting in the QuickConnects like you can with the Site manager settings for those who are unable to easily get these settings changed for their FTP server provider.

Fingers crossed you will do the right thing, but at least we have found a workaround for those using stateful packet inspection in their firewalls and hopefully it will help some who are burdened with this release.

[otherunicorn]

Resolution: Rejected
Solution: Deleting Filezilla.

End of line.

[Tim Kosse]

Explicit FTP over TLS is only used automatically if the server software advertises support for it.

If your server cannot handle explicit FTP over TLS correctly, e.g. due to a badly configured firewall, contact your server administrator or server hosting provider to have the server fixed.

If you cannot have the server fixed and you don't mind the lack of security, you can force use of plain FTP in the Site Manager of FileZilla as workaround.

[Az Cross]

If you are a VPS owner (sorry for those under the mercy of shared hosting D: ) you can use this guide to setup your server so that Filezilla 3.10.x+ works with your server. This is specific to CSF firewalls, but the same principle should work for most firewalls so change to your flavor.

[Az Cross]

Forgot the link: ​http://coolestguidesontheplanet.com/ftptls-ftpssl-working-vps-csf-firewall/

[spudgun007]

Welcome back codesquid.

Sorry but I disagree with this workaround because you cannot change it for the Quickconnects, AND you also gave no indication to users that this change was also made and gave the quick connect users no way to change it.

At the very least, they should be warned in the new version this change was made to let them know they can change it, and have a way to reverse it if they are not using site manager.

Yes, Site manager users can change it, but how are they supposed to know this is the issue and if they have no control over the FTP server, how can they get it fixed?

For all these users, filezilla used to work. Now it does not.

Yes, if you were knowledgeable enough and have control over the actual filezilla server you might be able to figure out it's due to stateful packet inspection and get your hosting provider to either remove that from the firewall or remove the option for explicit TLS in the FTP server software.

BUT THEY SHOULDN'T HAVE TO JUST FOR YOUR SOFTWARE.

I cannot stress enough that this is a major design flaw and it has caused your software to be hated amongst IT support professionals who have to change ftp clients or instruct hundreds of users of the work around if they cannot get the FTP server changed.

[Tim Kosse]

At the very least, they should be warned in the new version this change was made to let them know they can change it, and have a way to reverse it if they are not using site manager.

This change has been announced in the version history: "FTP over TLS is now used by default if the server supports it. Use of plain FTP can be enforced for a server in the Site Manager"

[...] IT support professionals who have to change ftp clients or instruct hundreds of users of the work around if they cannot get the FTP server changed.

Are you telling me that instructing hundreds of users is simpler than to just fix the server?

BUT THEY SHOULDN'T HAVE TO JUST FOR YOUR SOFTWARE.

Indeed. Finally you recognize that THEY HAVE TO DO IT FOR _ALL_ SOFTWARE USING EXPLICIT FTP OVER TLS.

[spudgun007]

By warned, I mean a prompt specifically about this change asking them if they want to change to use TLS by default, not just change it and put it in the release notes and hope for the best.

The vast majority of users I suspect are not actually reading everything that's changed whenever they upgrade.

Even if they did, most would have no clue what it means when it mentions TLS as to what this is and why this might cause it to fail.

Fixing the server isn't always as easy as you say if they don't know why this problem is occurring. It took us weeks to figure it out for our server. During that time we had users who had 100 saved ones in the quickconnect saved list, who were very angry at being told to recreate every single one of them as Site manager ones.

Even when they can figure it out, a big organisation has change control processes that can take months to get all the approvals and they do all the security testing required. Most would rather get rid of filezilla than do that.

It'd be fine in a small office with 8 people to make this small change, but not for a massive global organisation or a hosting company hosting thousands of such big companies SaaS applications.

I don't care about Site Manager and your workaround. I care about the Quick Connect users.

When I said they shouldn't have to, I meant the people running the FTP servers shouldn't have to make this change if they never had to worry about users using TLS over Explicit until you forced it upon them, and the filezilla users should not have to recreate the up to 100 or so Quick Connect settings they did which worked before while they are trying to sort this out.

If you must have TLS, I'm saying you ought to have a prompt asking if you want to change your quickconnects and sitemanagers to use TLS over Explicit by default. If this causes problems then go to this setting to change them back.

I'm not asking this for me, I've solved the issue.

I'm asking this for all other support professionals who will have servers who have to deal with this now and forever in the future when they have to deal with FTP servers which will have these problems.

You cannot guarantee that all users who use filezilla understand Plain vs TLS over explicit, and you cannot guarantee that all FTP servers will always be configured correctly and be easily able to be changed.

[Andrew]

"Indeed. Finally you recognize that THEY HAVE TO DO IT FOR _ALL_ SOFTWARE USING EXPLICIT FTP OVER TLS."

Yes, but all software has a setting for this, including FileZilla...EXCEPT for your Quick Connect option!

I'm a web developer. I have used FileZilla for many, many years. I only use your Quick Connect option for security reasons. I don't want client credentials saved in a plain text configuration file on my computer. So for those clients who only have plain FTP, I need Quick Connect to work! Simply telling their hosts "fix your TLS configuration" isn't an option. Especially when I am under a tight deadline.

There's 2 solutions: don't force TLS in QuickConnect if you're explicitly trying to connect via plain ​ftp:// , or tell every web host in existence "hey, fix your TLS configuration". Which is realistic?

Those of us living in the real world, with real clients, under real deadlines, don't understand why this is even being discussed.

[ZeroCool]

Replying to texmurph:

Something is amiss with the latest release 3.10.0 of FileZilla.
I have always downloaded and installed the latest version.
Today when I did that, FileZilla stopped working. Can you let me know
the fix, or point me to somewhere that I can download the previous version?
I am still running the previous version on my backup laptop, and FileZilla
works on that one. Server has not changed. Only FileZilla has changed, and this is the result:

Status: Resolving address of www.k9tag.com
Status: Connecting to 23.246.197.178:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is your current location
Command: TYPE I
Response: 200 TYPE is now 8-bit binary
Command: PASV
Response: 227 Entering Passive Mode (23,246,197,178,63,49)
Command: MLSD
Error: Connection timed out
Error: Failed to retrieve directory listing

At the end of the day, we are all more concerned with security than with mundane user preferences. This bug is not a bug, it is an improvement in security; standards are created to be followed, if they aren't going to be enforced because its inconvenient than lets hang up our hats and call the internet a security perfection zone. You can still specify a plain login under the sites, so just use that and own responsibility for your self inflicted vulnerability.

[Az Cross]

Look, I'm just going to chime in here because as a user, I have the same perspective as many of you. The new FileZilla really but a dent in my workflow. I had dev's calling me up saying the server was broken, and I initially went.. "nope it's stupid FileZilla!". But it isn't...

Let's take a simple and common use-case here. Let's say I was sending over a clients website or data via FileZilla, which I do daily. Later, the client calls me and is sensibly angry that the data was compromised by a third party. Where was the security they ask??

Well, I do some checking and it comes down to that data transfer. IF I HAD CONNECTED over TLS and FileZilla allowed it BUT I WASN'T actually using TLS and it was insecure, GUESS WHO IS AT FAULT. That's right, FileZilla!! And they should be in that case. I tried to connect with TLS, and the server replied "You can't! It's not secure", so FileZilla fails. That is as it should be.

Is it annoying. Yes. Has it screwed up my day to day (it did). But I had to change things over.

Now, I tell my clients (if I'm forced to use plain and no other encryption methods), "I can't connect to your server securely, either fix it or allow me to do it un-securely." (Which, let's be honest is OK a large portion of the time). And THAT IS AS IT SHOULD BE, that's the RIGHT way to do things. It's not as easy as before, but hey burying your head in the sand is always the easiest thing to do right?

FileZilla is great. It's a tool that has allowed me to survive doing what I love in an easy and intuitive way. Just because it won't lie anymore and allow us to connect over TLS without a secure handshake isn't reason to lose your minds. Get off this guys back and modify your workflow and deal with your clients in a meaningful way. If they are upset over this, take it up with the server owner, it's not our fault. (Or if it's your servers, like many of mine, JUST FIX IT. It's not hard and I linked a guide above).

TL;DR You have a great tool here, quit being entitled and realize it's working as it should. Maybe not the way you'd like, but it IS THE WAY IT SHOULD BE>

[spudgun007]

Sorry Grimpanda and 0kool, but I'm afraid I have to disagree with you there.

Security stopping users from using the application is far worse, especially when it doesn't actually tell you what the problem is. Users would rather login than it be so secure that nobody can.

If it actually gave a message saying you can't it's not secure, and it's because of TLS settings, then it would give the user and the owners of the FTP a clue of what to do. It just tells them it timed out.

Imagine a door company updating everyone's locks so that they were better but a large percentage of them could no longer get back into their houses and the way they always used to do it no longer worked, and there was no good feedback from the application as to why. Sure if you knew the trick to it you could get in, but most wouldn't know how to find it, and instead of making it so they could get in again, blamed the owners of the house for not having their house be compatible with your increased security measure.

I disagree that it's Filezilla's fault if it was compromised. Those who want the increased security have lots of other options to make it more secure like SSL, SFTP, VPNs and will pay for the privilege.

TLS over external is an optional thing. While it would be great if it worked as intended and all users who connected to an FTP which was configured to use TLS over external got better security without having to change anything, in reality that didn't happen. To assume that every FTP server in the world will be able to handle this is the height of ignorance.

To your statement "it won't lie anymore and allow us to connect over TLS without a secure handshake", that's completely wrong in this situation. It never lied, none of our clients were ever trying to do it this way. Had there been a requirement from a customer to use this I am sure we would have picked this up. It's only because there was no indication in the Quick Connect settings that this option is being used that so much confusion was caused. Those who used Site Connect at least were able to see that the option had been changed, and could change it. Quick Connect users had no clue. It was always using Plain, and users were happy to use that option. Filezilla is lying by omission by not saying it changed all their saved Quickconnect settings and giving no indication they did so.

Your statement of JUST FIX IT is not as easy as you think. For starters, Grimpanda's guide didn't help us as all with our firewall configuration, and it also doesn't help with multinational companies which take months to make firewall and server connections and have complex change control processes. If you belong to an organisation with 5 people with no change control you could not possibly understand how difficult something like that is to implement.

This is no about entitlement, this is about a terribly designed UI, changing the defaults and not giving any way to change them back for the Quick Connect users.

It's fine for those who can recognise there is an issue, but the message doesn't tell them this, it tells them it timed out.

To summarise, the main issues are:

1. Defaults were forced upon users who probably didn't read the TLS changes, or if they did wouldn't have understood them. They should have been informed and AGREED to change the option themselves. This is just as bad as facebook making everything default to public. At least Facebook though never changed everyones options on them and didn't give them a way to change them back.

2. There's no option to change this in the Quickconnect settings. At least they could give a new field for the quickconnect so they could change it to plain, right now you cannot. Try telling the person with over a hundred saved quick connect settings they have to recreate them all as site manger options and that it's really working if they only do this... they will not be happy.

3. The error messages are misleading saying it timed out and it's not related to the problem at all.

You say quit being entitled. Filezilla was the application that used to be the simple one for all the ordinary users. It's no longer the case now. This has ruined filezilla and has their stubbornness to fix this has completely ruined it.

It's fine for you who can figure it out, your average user who this tool was originally for, will be completely in the dark is now no longer able to

[Tim Kosse]

Imagine a door company [...]

Your analogy is flawed, it changes the root cause.

If you want an analogy, here's a car analogy:

Imagine a world where everybody drives compact cars. There are many underpasses and tunnels around through which the cars drive. Each underpass is marked with a sign that tells you the tunnel's clearance.
Each compact car is smaller than 2 height units and all tunnels and underpasses have a clearance of at least 3 height units.

Eventually trucks get invented, trucks are 4 units of height. Planning a route from place A to place B, the truck driver avoids all tunnels with a clearance of less than 5 height units.
Shortly after, the truck gets stuck in a tunnel where the sign indicates a clearance of 6 height units.

spudgun007 proudly proclaims "The truck is at fault!", without considering that somebody must have put up a sign that doesn't match the tunnel.

[spudgun007]

Your truck analogy is not valid in the sense that it's required to be that big to get through, and it's obvious why there's a problem. In this analogy the truck used to be able to get through the tunnel for years until your new toll booth system came in and suddenly it got stuck but would give no reason why and no way to fix it in the truck unless you happened to know the trick to it.

This sign is also not obvious in this scenario. I get the FTP client behind the scenes gets the message TLS is supported but to your average user, all they know is it's not working, like your toll tag got the message and beeped differently but the user doesn't have any clue what it means.

I agree that there is a problem with an FTP server, but the problem is you made it a problem that cannot be fixed in the client application, and reports an error that is not at all obvious that this is the problem.

You're acting like using TLS over Explicit was a requirement for everyone that everyone asked for. It wasn't.

If it was a requirement, and we chose to use TLS over Explicit to connect, then I'd be happy to blame the FTP server administrators, and the appropriate actions would be taken by them to fix it. If all servers in the world were perfectly configured and extremely easy to fix if not we wouldn't be having this conversation.

I'm not arguing that there's a problem in the FTP server with using TLS over explicit, and the people who managed it should have tested this scenario if they had the time. However this is the real world where mistakes are made and not every single scenario is tested, and most of the time this isn't something that a customer will require.

1. The user doesn't know they are using TLS over explicit for their Quick Connects now.

2. The user doesn't know that this is the problem, all they see is a time out.

3. Even if the user does know, there's no way to change their Quick Connect. I don't care that they can create a brand new Site Connect with plain, you need to fix the Quick Connect.

At the very least, add the Encryption as a new field to select for Quick Connect so that it can be changed, and give a message to users to say your Quick Connects have been upgraded to use TLS over Explicit if supported. If this needs to be changed this is how you change it.

I am still against you changing all our existing defaults and settings without asking and would prefer they not be changed, but I am willing to compromise if you can just inform users and give them a way to change it if there's an issue.

This way you keep your extra security by default, and users can know this has changed and change it back if it's an issue until the FTP server's owners can change it so that they can use TLS over Explicit and they can change it back to get the extra security.

What do you say, it's been 2 months, and this solution keeps your added security by default and helps all other IT support professionals by informing the user and giving them a way to fix it in the UI. I'd believe in this product, and would like to believe that we can come together and resolve this instead of constant reopening and closing of this ticket.

[niente]

I agree with spudgun007, I used FileZilla for years, now it suddenly started to show Timeouts. It took me some time to understand why, and I was disappointed when I didn't even find a "Disable TLS as default" option in preferences. Hope it gets added.

[Az Cross]

I have to agree that more knowledge or settings is critical as well. The ONLY reason I didn't stop using FileZilla was simply because I found this while researching the issue. I can see many people not doing that and just giving up as I was about to. I too believe three things should be added if you want to be safe and not frustrate the end-user. 1) A pop-up upon first run after upgrading/installing with the new change. It should explain briefly and simply that if the TLS/ex method fails, it's likely a server mis-configuration and they should have their IT people correct it or attempt another method. 2) It should have a simple error log message (TLS may fail on mis-configured servers, consider trying another connect method or ensure the destination server is configured correctly). 3) Add an option to quickly switch this default in the QuickConnect.

I believe this is critical for your user experience and retention rates.

[Tim Kosse]

Your truck analogy is not valid in the sense that it's required to be that big to get through, and it's obvious why there's a problem. In this analogy the truck used to be able to get through the tunnel for years until your new toll booth system came in and suddenly it got stuck but would give no reason why and no way to fix it in the truck unless you happened to know the trick to it.

You're making the wrong assumption that trucks were used in the past. This however is not the case.

In the past you were not using a truck. In the past you were using a compact car. You are only now using a truck because the sign in front of the tunnel says that the truck fits. If the sign would say that the truck doesn't fit, you'd still use a compact car.

The problem is that the sign doesn't match the tunnel, the tunnel is smaller than the sign says it is.

If you want this fixed, either have the tunnel widened or the sign replaced.

[spudgun007]

We are not arguing that there's a problem with an FTP server was configured to use TLS over Explicit which nobody every actually used for years.

If you insist on using your car/truck analogy, in this case, filezilla is actually the car, and you have turned it into a truck without telling the driver. (yes you can say it was in the upgrade notes but nobody reads them just like nobody reads what they accept in terms and conditions, or if they did they would mostly not understand it).

Yes, the tunnel was configured to allow trucks, but for 10 years no truck ever drove through, and nobody ever asked to have trucks go through, so it was never an issue. Had a truck been required then they'd gladly fix the tunnel.

And this "sign" is something only the car recognises and the users has no idea that this is the problem.

Fixing these "tunnels" requires a lot of council approval, an awful lot of work to make it wider if it's a particularly big tunnel servicing a lot of cars, and would be too hard to fix and likely be told to get a new car when they don't know the issue.

Even when they know what the issue is, the users of the car have no way to change it back from a truck to a car.

All you are doing is closing this ticked over and over and saying the FTP server is at fault and needs to be fixed, but haven't explained how you are going to ensure that every FTP server in the entire world is suddenly going to be able to be fixed to cater for this, and how all ordinary users in the world are going to realise that this is the problem and know how to correct it and not abandon filezilla.

You say it's really easy to identify and fix, but tons of people have been refuting this in this thread and many others. Yes we eventually did turn off TLS over explicit to get around it after a month of troubleshooting, but a lot of our customers abandoned filezilla in the process while they were waiting for the fix.

How about you tell me why you should not let users know that you have changed all quickconnects to use TLS over explicit and provide a new field for Quickconnect to allow them to change it like you have in the Site Connect setting. Maybe you can't indicate that the problem is the TLS setting, but at least find a way to fix it. This is not just me saying this as you can see with the other posts.

[Tim Kosse]

Please stop reopening this issue.

[spudgun007]

If the issue was addressed then there would not be a need to keep reopening it.

You don't have to keep replying only to me, you can also reply to the other users who are complaining as well.

If you read the other users replies, a lot agree with you about the security side of it, and I can appreciate that you meant well in changing the default so everyone would have more secure FTP if the server says it supports it. I can also appreciate that a server which advertises it supported this should not have and should have been tested for this as well.

However, NOBODY agrees with you regarding the user interface with Quick Connect defaulting to this Encryption setting, not informing users that this was done, and not giving any way to change it. Even Grimpanda who I was arguing with agrees with this.

Quick Connect historically was always the default easy mode for everyone because it allowed them to simply put in the Host, username and password (and port but usually didn't have to when using port 21) and it worked for everyone.

If you wanted additional encryption or any of the other more advanced settings then you could do so with the Site Connect settings.

I didn't like changing the defaults of the Site Connect, but at least you could change that if you wanted. You cannot change Quick Connect settings.

If you have changed the Encryption from the Default now, you MUST give a way to change it in Quick Connect too. At the very least you need to have an Encryption Field Available in Quick Connect so that users can change that too and at least see something that's changed.

You can then tell all users that you are doing them a big favour by changing all their settings to use the more secure TLS over Explicit setting for Quick Connect and Site Settings, and let them know if they don't like it they are free to change it back to Plain if it means that it no longer works.

I don't think you realise how much stress this update caused our company. We had not changed anything about our FTP server and yet it was failing. The only thing that changed was Filezilla.

While I and Grimpanda were able to work it out, most users who get this issue will abandon it and use something else which can work while the issue is fixed (if it gets fixed at all). Is this what you want?

Would you rather Filezilla stop being used?

I am happy to keep the security setting, I'm happy for it to be the default, just make it possible to undo in Quick Connect, and tell the users that this has been done.

Don't let this be the death of a the great application you developed back in 2001. I wouldn't keep doing this if I didn't care so much about this product.

[Tim Kosse]

Please stop reopening this issue.

[Dennis]

At least make the error meaningful.
Just Timeout is no on.

When I struck this problem I had no idea what was the problem. I had to search and find this forum and then read through until I found that I had to set the encryption to 'Use only Plain FTP (insecure)'.

Once I did that all was well again, but most people are not IT savvy enough to go do that.

Get you head out of the sand and DO SOMETHING and we will stop reopening this BUG.

[Tim Kosse]

Okay, I'll do something. I'm going to tell you to contact your server administrator or server hosting provider so that they can fix the server.

Contact your server administrator or server hosting provider so that they can fix the server.

[Dennis]

I have brought it to the attention of JustHost a couple of months ago, and I am just one voice. They don't believe they have a problem.

I, and probably many others are happy to run Plain FTP, if we know that's what a simple single user must do if the large Host is not going to do anything, that's fine ... Just put up an error message so the average punter knows how to work around the problem.

Connection timed out tells you nothing!

Be professional and assist your users.

[LexLechz]

Even on ​https://ftptest.net/ users have the choice to force the "Plain FTP (insecure)" connection. Only FileZilla can not.

1) In meantime we all agree that this is NOT A BUG. But the ability to force insecure connections would be a great feature satisfying all users that have re-opened this issue again and again.

2) It would be helpful to improve the timeout message for secured connections. Regardless if security was activated automatically or the user forced it. Not every FileZilla user is able to enable debugging and locate the cause of the timeout. I'm sure that most users only have noticed that the connection is not working and switched to another program. They did not notice that it's NOT a real FileZilla problem but the problem of their provider - or more worse: a 3rd party provider!

[Tim Kosse]

See comment 48 on the timeout message and why changing it is really bad idea.

[Dennis]

Replying to codesquid:

Okay, I'll do something. I'm going to tell you to contact your server administrator or server hosting provider so that they can fix the server.

Contact your server administrator or server hosting provider so that they can fix the server.

Two months ago I contacted my Host:-

Good Morning,

I use FileZilla to upload my files to my website hosted by Just Host.

Until recently this has been a very smooth arrangement. With a recent 'upgrade' of FileZilla, version 3.10.0.2 a fatal error in connection occurs.

Searching for a solution, I have come across this discussion:-

FileZilla Version 3.10.0.2 sets Encryption as "Use explicit FTP over TLS if available" as the default.
Filezilla says if this does not work then the Host Server is incorrectly configured - contact your Host.
Discussion is here:-

​http://trac.filezilla-project.org/ticket/9995#comment:24

As you see, FileZilla wishes to discuss what needs to be done.
As requested I am asking you to please contact FileZilla to understand why you need to change your Server settings.

Kind regards

And this was their reply:-

Hello,

Thank you for contacting our Technical support department. We apologize for the inconvenience that you have experienced.

Filezilla is a third party application. The upgrade process that you have mentioned has been performed from their end. We are not able to contact them regarding this issue.

If you need further assistance with this matter, please feel free to reply to this email. But before we can proceed we need you to validate ownership of the account by giving us ONLY ONE of the following:

• The last four characters of the current password on your account.
• The last four digits of the credit card used for the most recent web hosting payment.

If you have other issues we can assist you with, please open a new ticket.

Help us improve our support by answering a quick survey: ​http://survey.justhost.com/s3/Zm7d25G6HJ

Thank you,

Keerthi
Level I Tech Support Engineer
Justhost.com
888.755.7585

Find answers immediately using our online help resources:
Knowledgebase: ​https://www.justhost.com/cgi/help
Tutorials: ​http://www.justhost.com/tutorials

Have you contacted JustHost? Would you PLEASE contact JustHost?
Realistically we need YOU to action this as WE cannot.
I am running FTP plain but others don't know how or can't for various reasons.

Either work with the Hosts or at the very least, post an explanatory error massage, not just "Connection Timed Out"

Thank you

[spudgun007]

I doubt Codesquid is going to contact them. Even if he does, he'd need to contact all hosts of FTP servers and fix their settings or firewalls in order to be able to keep it like this, and ensure that all newly created ones are also correctly configured.

@Codesquid, can you PLEASE for a moment imagine that your users are not developers who have been developing FTP clients and servers for the last 14 years and try to put yourself in a regular users shoes.

Any time suddenly users cannot connect, we always ask What has changed. scorpion61's issue is JustHost as far as they're concerned haven't made any changes, therefore the problem must be with the customers changes.

We know that JustHost has a problem, and they should not have said they support TLS over Explicit without testing it, but unless you personally are going to go on TV to announce this, or personally contact every host of every FTP server in the world and personally fix this issue, it's going to remain a problem.

And put yourself into the shoes of an ordinary user, perhaps a relative you have who is bad with computers who would get this message who doesn't read all your release notes and just updates without thinking. As far as they can tell, what has changed for them? They haven't changed their Quick Connect setting either, and cannot see that it's using the new encryption method.

I agree that Filezilla is working correctly if the server is correctly configured, and I'd love it if this got all FTP servers in the world to be able to be configured correctly but it's not going to happen.

These are the options I think you have.

1. Change the Quick Connects back to Plain and default their new ones to Plain.

This is the simple version that has always been used for the last 14 years that users know works and works for all FTP servers in the world that worked with the previous versions. By all means have new Site Connect default to use TLS over Explicit, at least they can see this is the setting there and can change it if it fails. While the default ones will be less secure, your ease of use will be back to the way it always used to be and you will get your users back working again.

2. Add the Encryption option to Quick Connect.

This way, users can see clearly something has changed about their Quick Connect, and you can show a screenshot in the release notes and make sure they notice it and agree to make the change so they know it's different now. They can then choose to use the less secure plain mode if they want.

I realise they've always been less secure when they used the Quick Connect and probably never realised it was less secure. Let them know that they have been, and let them decide to change it and then they can show that it works in Plain mode, and can contact their Hosting company to get it to work under TLS over Explicit if they wish.

This may make the Quick Connect more complex, but at least has now the option to change it. Ideally you could change it for all in one hit for those of us who have hundreds of saved Quick Connect entries, but that'd just be a nice to have.

3. Continue to be stubborn and not read or consider our posts and continue closing this issue for the rest of your life while all your original loyal users abandon the application you put your heart and soul into for the last 14 years.

I've been a developer and support, and seen how attached developers can be to their designs who refuse to make minor changes to what they put their heart and soul into. Please don't be that guy who refuses to change and says that everyone else should change to accommodate you.

[Andrew]

Is there any chance that the suggestions made here will be implemented? Some sort of UI change to the Quickconnect feature, allowing people to connect with plain FTP if they choose? My current "fix" was to go back to an old version of FileZilla, because contacting dozens of web hosts to ask them to fix their FTP servers isn't an option, nor is it realistic. However, giving something in the UI which enables Quickconnect to just use plain FTP is realistic, and just makes plain sense. As stated in a previous message, I don't use the Site Manger for security reasons, I only Quickconnect. I like FileZilla, always have, but if we don't get an option to allow plain FTP in the Quickconnect feature, I'm going to have to abandon it.

[Simon]

Hi all,
I have just read this ENTIRE thread and have come to three conclusions, written tone and mudslinging aside, you all might consider.

1)
The change to FileZillas QuickConnect that it will attempt FTP over TLS if the server advertises it, is seemingly a permanent change that we should not expect to be changed. (codesquid = Tim Kosse)
Yes it will, in all practicality, render the FileZilla Client useless to (my guess) >90% of its users that uses it against servers that advertises FTPoverTLS capability without having it properly set up. (That is the condition and Tim is right in claiming this is NOT a bug in FileZilla)
This is Tim Kosses descision and we can shake our heads in wonder - but this IS his baby and he decides its fate.

2)
Resolution options are:
a) stop using QuickConnect and instruct users to create an entry inside the Site Manager and set the connection to PlainFTP specifically.

b) Tell (not ask) your FTP server provider to make it stop advertising FTPoverTLS -or- configure it properly. The latter will require certificate and firewall configurations that most providers might not be willing to do (for free at least) or simply have no clue how to achieve (ie you should change provider)
Tim provided this link to test your FTP server ​https://ftptest.net/

c) Use another FTP that does not "require" FTPoverTLS. I all fairness FileZilla does not "require" FTPoverTLS with this change - it simply NOW opts to use the most secure method advertised by default.

3)
We can pledge a feature request to keep FileZilla the #1 preferred FTP client for users.
The feature request is to alter the QuickConnect button to make users opt for PlainFTP as default. Either directly somehow on the button or as an option inside the Edit/Settings tree.
So hereby pledged.

[spudgun007]

I think by now anyone on this thread has probably already gotten around it one way or another by either not using this version or getting their server to fix it. It's not about that now, it's about the UI and usability.

"Technically" you could say Tim's correct in that the problem isn't filezila's, but it's only a problem because Filezilla made it a problem and it's something a quickconnect user cannot fix. You are correct it's his decision, but I will not stop trying to change his mind.

I have given up on Tim changing the default to use Plain again. From a security perspective one can see its merits, but from a UI and a useability point of view it has to change.

All I ask now is a UI change with something that informs the user that this has changed so that they can choose to change it back to Plain in Quick Connect mode.

Come on Tim, just add that one extra field so everyone can see that Quick Connect is using this mode so that they can change it, and show it in the Change log with a screenshot.

This would satisfy almost everyone here.

I know you can use Site Connect but many don't want to use as you can see from other posts and most I'd assume won't know how to fix it.

If this is to be a feature request, then I'm happy to keep it as such but I'm reopening it.

If Tim rejects the feature request then I guess there's nothing we can do, but I really hope that he considers making this change so that Filezilla can once again become the preferred client.

[Dennis]

Replying to spudgun007:

<snip>

I know you can use Site Connect but many don't want to use as you can see from other posts and most I'd assume won't know how to fix it.

I am one that MUST use FTP Plain because my host can't, won't, or is not bothered to change his settings.

My Solution:-
Once set to Plain in Site Manager, I don't use 'Quick Connect', I use the Green 'Tick' to connect to the last used server. This 'remembers that I am using 'Plain'.

Works for me!!!

[spudgun007]

Thanks Scorpion61. I myself have managed to login and managed to finally get our hosted server to stop advertising it does support TLS over Explicit since it also has stateful packet inspection.

I'm asking for there to be an option to change from TLS over Explicit to Plain and any of the other options that Site Connect has in Quick Connect on behalf of all IT professionals who have to support this product now and in the future who may encounter this problem so that customers know that its changed and can change it.

What do you say Tim? With all the complex stuff can you do this one thing? I promise I won't reopen this ever again if you do.

[Slion]

I came across that problem today after updating filezilla. It took me a while to figure it out. I don't think I've used anything else than quick connect until now.
I guess, it's fair enough to ask people to create an entry in Site Manager to workaround a server misconfiguration. Though it would be nice to have an explicit error message. something like: "Failed to connect using TLS. Please create a Site Manager entry and try using a Plain connection instead".

[Tim Kosse]

Though it would be nice to have an explicit error message. something like: "Failed to connect using TLS. Please create a Site Manager entry and try using a Plain connection instead".

Bad idea, see comment ​http://trac.filezilla-project.org/ticket/9995#comment:48

[Andrew]

Replying to Slion:

I guess, it's fair enough to ask people to create an entry in Site Manager to workaround a server misconfiguration.

I disagree that this is a fair option. Credentials aren't securely stored by Filezilla, and can easily be exported to an XML file --- everything in plain text. I much prefer using Quick Connect so I'm not storing client credentials in a way that someone could easily steal if my laptop were to ever be stolen. This is why having a UI option for Quick Connect to allow plain FTP is crucial. I've got dozens of clients...I can't control their web hosts and force them to identify TLS correctly.

[spudgun007]

@codesquid with all due respect, can you please reply to more than one thing and not just the one you had a good reply to a while ago.

Yes I get that it's a potential security risk to automatically fall back to plain if it fails like that. Those of us who have been on this for months have given up on that one.

What we're now asking for is just one extra column for Quick Connect for Encryption so one can clearly see that Quick Connect uses TLS over Explicit and can change it if they have to. A message in the What's New with a pic of this new column would also hopefully make it clear to most they now have this and it's using TLS over explicit to make them more secure.

You'll satisfy almost everyone here who uses Quick Connect to give them a work around until they can get their Host sorted out.

Is this possible Tim?

[attaattaatta]

Finally solved

Add 125:7 (ftp_pp: FTP command channel encrypted) to the exclusions of our Snort IDS system, and it do the job.

But WHY FileZilla do not question the enduser with the failed connection ?

It would be great if Filezilla will ask (and warning) for plaintext when TLS fail.

[Tim Kosse]

To quote myself:

Please stop reopening this issue.

[jamurforex]

Try this...
go to site manager
change encryption to : use plain FTP
change your user name: your username@your domain (exp: textmurp@…)
try connect

[nick.theboatman]

I've just read the history in this ticket and I have to say that I am appalled by the attitudes being displayed here - however it doesn't help to go back into the history except to say that this is reminiscent of the compatibility wars that used to rage in the 90s: so GET WITH THE PROGRAMME and make this work.

Because this is still broken, 2 years on.

Failing which, obviously, I will stop using this product and recommend to others the same response. Including the ISP I have been fault-finding with (see below).

So:

1. When Fz starts, if it cannot negotiate "implicit TLS" on a site purporting to advertise TLS, Fz fails to connect.

2. Work around: force "non-TLS" instead of the Fz default mode of "implicit TLS" prevalent post v3.8 or so.

3. This thread has been batting back and forth blaming Fz, then blaming the ISPs server config etc. No reference to the subtleties of _where_ the incompatibility arises (routing, firewall rules, server issue, Fz issue, certificate problem blah).

4. I have just spent 3 hours of my New Year's Day holiday for a client on the phone to the ISP (duty person also not relaxing on New Year's Day) to work through the same thing happening with this situation (Fz v 3.16.1)

5. In the thread is a reference to ftptest.net. Using this and in particular accessing the ISP FTP server and forcing explicit TLS over FTP, the test passes:

Status: Resolving address of <a.b.c.d>
Status: Connecting to <n.o.p.q>
Status: Connected, waiting for welcome message...
Reply: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
....
Command: CLNT ​https://ftptest.net on behalf of <e.f.g.h>
Reply: 530 You aren't logged in
Command: AUTH TLS
Reply: 234 AUTH TLS OK.
Status: Performing TLS handshake...
Status: TLS handshake successful, verifying certificate...
Status: Received 3 certificates from server.
Status: cert[0]: subject='OU=Domain Control Validated,OU=PositiveSSL,CN=<a.b.c.d>' issuer='C=US,ST=TX,L=Houston,O=cPanel\5c, Inc.,CN=cPanel\5c, Inc. Certification Authority'
Status: cert[1]: <stuff>
Status: cert[2]: <stuff>
Command: USER <name@place>
Reply: 331 User <name@place> OK. Password required
Command: PASS *
Reply: 230 OK. Current restricted directory is /
blah.....

So we know that (a) routing (b) firewall rules and (c) server config are not interfering with the negotiation.

6. Using Fz, using sitemanager to force "explicit TLS" fails:

Status: Resolving address of <a.b.c.d>
Status: Connecting to <n.o.p.q>:21...
Status: Connection established, waiting for welcome message...
Status: Initializing TLS...
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of <a.b.c.d>
Status: Connecting to <n.o.p.q>:21...
Status: Connection established, waiting for welcome message...
Response: 220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response: 220-You are user number 4 of 50 allowed.
Response: 220-Local time is now 17:24. Server port: 21.
Response: 220-This is a private system - No anonymous login
Response: 220-IPv6 connections are also welcome on this server.
Response: 220 You will be disconnected after 15 minutes of inactivity.
Command: AUTH TLS
Response: 234 AUTH TLS OK.
Status: Initializing TLS...
Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server

So it follows that the TLS negotiation is failing. Given that ftptest.net shows negotiation using "explicit TLS" passing this suggests a problem with Fz.

7. The "fall back to insecure operation" work-around might represent an engineering work-around but not an operational one. If it was me hiring a VP Engineering who did this, in today's climate, I'd sack him. Because in today's climate it is highly irresponsible (to the point of being negligent) to suggest working in an insecure manner. And the VP would known that. Equally so does the Fz development team.

So, ladies and gentlemen, let's not get back into that tit-for-tat crap that was flying around before, and do some _proper_ fault resolution. Please?

[Tim Kosse]

Let's untangle this mess one statement at a time.

1. This ticket has nothing to do with implicit FTP over TLS, it is merely the fallout of enabling opportunistic use of explicit FTP over TLS, which is the default mode.

2. Yes, the manual fallback is for those situations in which the problem is unsolvable for political reasons (as there is never a technical reason why it cannot be solved). Note that there is no automatic fallback since they are insecure (downgrade attack).

3. The issue is almost always caused by badly configured or broken servers and their firewalls and NAT routers, or occasionally a badly configured or broken client-side firewall or NAT router. It just isn't an issue in FZ. I feel as if I'd be a doctor arguing with a crowd of anti-vaxxers. That said, it's not my job to diagnose the precise cause of a server-side issue, that's the job of the server administrator.

4. What do I do with that information? It's not relevant to the discussion.

5. That makes a server-side issue unlikely.

6. Since FZ and ftptest.net share a common code base, a bug in FZ is highly unlikely. Combined with 5., you've established that the problem is most likely with a client-side firewall or NAT router. For a test, try _uninstalling_ (as disabling them leaves their drivers running) all firewalls and if you're using a NAT router, plug your computer directly into your modem.

7. I agree. Problems must be solved at the source, not worked around.