GnuTLS error -12 when trying to connect to with Explicit TLS

[xeon]

I don't see how saving cpu cycles is silly. People who say this don't seem to understand just how much is wasted by using a cipher like 3DES.

If anything needs to be done it's vsftpd's dev needing to change their default cipher to something more efficient such as AES/RC4 or perhaps even multiple ciphers this time.

As for anyone else you have no one but your server admin to blame if they aren't able to take 5-10 seconds out of their day to change the default cipher on their ftp servers.

If an admin can't even do that maybe it's time to find a new host or admin?

I never said saving CPU cycles is silly. But it is silly that you feel the need to save other people's CPU cycles by FORCING them to switch hosts. Who makes you the person who decides what should be more important for us?

Leaving it as an OPTION allows the best of both worlds. Period.

You get what you want and so does everyone else.

I am not going to pay more money to switch to another host so I can use FileZilla's latest client.

Ridiculous.

No one said anyone had to switch hosts. I was merely offering the suggestion that if your current host is unable to perform simple tasks maybe you'd be better off moving to a competent host.

There's absolutely zero reason for anyone to be using the default 3DES cipher selection you sacrifice nothing and gain everything by switching to something like AES/RC4.

What did your host tell you when you brought it up? I can't imagine any competent hosting provider saying no to saving resources while increasing security at the same time.

[cecemel]

Just found a sloution for vsftpd, from this thread, I added ssl_ciphers=HIGH to the vsftd.conf and the latest FileZilla can now connect to the FTP server again.

Thank you for this - I was faced with this problem from one of our customers today and this was the answer.

I had the same issue as well. Fixed! Thanks!

[jron]

I just registered to thank the developers for wasting 2 hours of my life and breaking compatibility with thousands of servers. What's next, the removal of basic FTP authentication because servers shouldn't be using it?

I share the previous poster's sentiment - ridiculous!

[boco]

What's next, the removal of basic FTP authentication because servers shouldn't be using it?

No, but automatically using FTP over TLS whenever possible by default is planned.

[henriik]

Just found a sloution for vsftpd, from this thread, I added ssl_ciphers=HIGH to the vsftd.conf and the latest FileZilla can now connect to the FTP server again.

Thank you for this - I was faced with this problem from one of our customers today and this was the answer.

I had the same issue as well. Fixed! Thanks!

Thanks. Worked for me too.

[iNDiGLo]

I have Filezilla 3.5.3 running on my Macbook Pro running Mountain Lion and it works fine.

I tried upgrading to 3.6.0 today and it broke my Explicit TLS connection to several FTP Servers.

I FTP into my ISP to my website all the time using Filezilla. I didn't change anything in my my Site Manager but now none of my sites work. So...

I read earlier posts in this thread where people claim that 3.5.3 broke their Explicit TLS connectivity but for me 3.5.3 works fine but 3.6.0 broke it.

I hope there is an update for this problem soon. I'll be monitoring this thread.

[xeon]

I have Filezilla 3.5.3 running on my Macbook Pro running Mountain Lion and it works fine.

I tried upgrading to 3.6.0 today and it broke my Explicit TLS connection to several FTP Servers.

I FTP into my ISP to my website all the time using Filezilla. I didn't change anything in my my Site Manager but now none of my sites work. So...

I read earlier posts in this thread where people claim that 3.5.3 broke their Explicit TLS connectivity but for me 3.5.3 works fine but 3.6.0 broke it.

I hope there is an update for this problem soon. I'll be monitoring this thread.

What error(s) are you receiving? You should really copy/paste your log here.

[iNDiGLo]

21:34:31 Status: Resolving address of example.com
21:34:31 Status: Connecting to 69.8.159.222:5051...
21:34:31 Status: Connection established, waiting for welcome message...
21:34:31 Response: 220 WEB05:5051 FTP server (Version 1.5) ready - 1
21:34:31 Command: AUTH TLS
21:34:31 Response: 234 Security data exchange complete
21:34:31 Status: Initializing TLS...
21:34:31 Error: GnuTLS error -12: A TLS fatal alert has been received.
21:34:31 Error: Could not connect to server
21:34:31 Status: Waiting to retry...


This is the log from version 3.6.0. Fails to connect every time. If i go back to 3.5.3 it works fine.

[xeon]

21:34:31 Status: Resolving address of example.com
21:34:31 Status: Connecting to 69.8.159.222:5051...
21:34:31 Status: Connection established, waiting for welcome message...
21:34:31 Response: 220 WEB05:5051 FTP server (Version 1.5) ready - 1
21:34:31 Command: AUTH TLS
21:34:31 Response: 234 Security data exchange complete
21:34:31 Status: Initializing TLS...
21:34:31 Error: GnuTLS error -12: A TLS fatal alert has been received.
21:34:31 Error: Could not connect to server
21:34:31 Status: Waiting to retry...


This is the log from version 3.6.0. Fails to connect every time. If i go back to 3.5.3 it works fine.

If it's the same problem as everyone else in this thread, then it's due to the server not supporting any of the ciphers FileZilla Client allows.

Between versions 3.5.3 and 3.6.0, the most common cipher that was excluded is RC4-SHA, perhaps your FTP server only allows that cipher?

[iNDiGLo]

If it's the same problem as everyone else in this thread, then it's due to the server not supporting any of the ciphers FileZilla Client allows.

Between versions 3.5.3 and 3.6.0, the most common cipher that was excluded is RC4-SHA, perhaps your FTP server only allows that cipher?

If you are correct about the cipher i wish there was a configuration file on the client in versions 3.5.3 - 3.6.0 that we could modify to add checking for RC4-SHA back. I suppose at this point we have to wait for another 'maintenance' release?

[xeon]

If it's the same problem as everyone else in this thread, then it's due to the server not supporting any of the ciphers FileZilla Client allows.

Between versions 3.5.3 and 3.6.0, the most common cipher that was excluded is RC4-SHA, perhaps your FTP server only allows that cipher?

If you are correct about the cipher i wish there was a configuration file on the client in versions 3.5.3 - 3.6.0 that we could modify to add checking for RC4-SHA back. I suppose at this point we have to wait for another 'maintenance' release?

If you want, you can provide the public IP address of the server, I could tell you for sure what's causing it then.

[boco]

I somehow doubt that botg will re-enable weak ciphers. Consider them gone for good.

[iNDiGLo]

If previous versions of FileZilla have connected to my ftp locations with no problems but the new version no longer does that pretty much leaves most of us with two choices:

1. Continue using an older version of Filezilla
2. Look for a different FTP Client

I can't control what my ISP or other FTP locations choose to use as an FTP Server. Therefore i can't make the new version of FileZilla 'conform'.

Of the 2 choices above, which do you think is smarter for the 'user base'?

[boco]

Of the 2 choices above, which do you think is smarter for the 'user base'?

Choice #3
3. Contact the server support and demand your right as customer for your data to be protected. Don't just ask, demand. It is usually only a little switch in the configurations of the server. If they fail to do anything you should change to a different provider. Some will only learn through financial loss.

Of course choice #2 is always a viable one. It is your right to look for an alternative FTP client.

However, choice #1 is not recommended. Should a security issue ever be detected, it will be fixed in new versions only.

[xeon]

I somehow doubt that botg will re-enable weak ciphers. Consider them gone for good.

3DES got added back in somehow, which I consider far worse than RC4. RC4 isn't weak when used in the context of SSL/TLS anyway.

It looks like the flags he used "SECURE256:+SECURE128", the "+" adds 3DES back in for some reason, "SECURE256:SECURE128" without the "+" doesn't list 3DES at all...