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

[Technofrood]

I use FileZilla to connect to a vsftd (2.0.7) using Require explicit FTP over TLS, this was working fine until an upgrade to 3.5.3, I know get "GnuTLS error -12: A TLS fatal alert has been received." every time I try to connect.

Code: Select all

16:05:15	Status:	Connecting to serverip:21...
16:05:15	Status:	Connection established, waiting for welcome message...
16:05:15	Trace:	CFtpControlSocket::OnReceive()
16:05:15	Response:	220 (vsFTPd 2.0.7)
16:05:15	Trace:	CFtpControlSocket::SendNextCommand()
16:05:15	Command:	AUTH TLS
16:05:15	Trace:	CFtpControlSocket::OnReceive()
16:05:15	Response:	234 Proceed with negotiation.
16:05:15	Status:	Initializing TLS...
16:05:15	Trace:	CTlsSocket::Handshake()
16:05:15	Trace:	CTlsSocket::ContinueHandshake()
16:05:15	Trace:	CTlsSocket::OnSend()
16:05:15	Trace:	CTlsSocket::OnRead()
16:05:15	Trace:	CTlsSocket::ContinueHandshake()
16:05:15	Trace:	CTlsSocket::OnRead()
16:05:15	Trace:	CTlsSocket::ContinueHandshake()
16:05:15	Trace:	CTlsSocket::Failure(-12, 10053)
16:05:15	Trace:	GnuTLS alert 40: Handshake failed
16:05:15	Error:	GnuTLS error -12: A TLS fatal alert has been received.
16:05:15	Trace:	CRealControlSocket::OnClose(10053)
16:05:15	Trace:	CControlSocket::DoClose(64)
16:05:15	Trace:	CFtpControlSocket::ResetOperation(66)
16:05:15	Trace:	CControlSocket::ResetOperation(66)
16:05:15	Error:	Could not connect to server
16:05:15	Trace:	CFileZillaEnginePrivate::ResetOperation(66)

Just tested with WinSCP and that works fine.

I can't see anything going wrong in the server side logs.

[boco]

Yes, it's the same for me. 3.5.3 broke TLS with my servers, too. For the time being, I'm back to 3.5.2.

18:53:11 Status: Resolving address of natalya
18:53:11 Status: Connecting to 10.0.0.3:21...
18:53:11 Status: Connection established, waiting for welcome message...
18:53:11 Trace: CFtpControlSocket::OnReceive()
18:53:11 Response: 220-zFTPServer (licensed) v6.0, build 2011-10-18 10:24 ready.
18:53:11 Response: 220-
18:53:11 Response: 220-Hello, 10.0.0.3!
18:53:11 Response: 220-Current date & time: 2012-01-10, 18:53
18:53:11 Response: 220-You are user 1 of 20 allowed.
18:53:11 Response: 220-Currently logged on users: 0
18:53:11 Response: 220-Uploaded/downloaded total: 466.03 GiB up / 1.22 TiB down
18:53:11 Response: 220-
18:53:11 Response: 220 Have fun!
18:53:11 Trace: CFtpControlSocket::SendNextCommand()
18:53:11 Command: AUTH TLS
18:53:11 Trace: CFtpControlSocket::OnReceive()
18:53:11 Response: 234 AUTH Command OK. Initializing SSL
18:53:11 Status: Initializing TLS...
18:53:11 Trace: CTlsSocket::Handshake()
18:53:11 Trace: CTlsSocket::ContinueHandshake()
18:53:11 Trace: CTlsSocket::OnSend()
18:53:11 Trace: CTlsSocket::OnRead()
18:53:11 Trace: CTlsSocket::ContinueHandshake()
18:53:11 Trace: CTlsSocket::OnRead()
18:53:11 Trace: CTlsSocket::ContinueHandshake()
18:53:12 Trace: CTlsSocket::OnRead()
18:53:12 Trace: CTlsSocket::ContinueHandshake()
18:53:12 Trace: CTlsSocket::Failure(-12, 10053)
18:53:12 Trace: GnuTLS alert 47: Illegal parameter
18:53:12 Error: GnuTLS error -12: A TLS fatal alert has been received.
18:53:12 Trace: CRealControlSocket::OnClose(10053)
18:53:12 Trace: CControlSocket::DoClose(64)
18:53:12 Trace: CFtpControlSocket::ResetOperation(66)
18:53:12 Trace: CControlSocket::ResetOperation(66)
18:53:12 Error: Could not connect to server
18:53:12 Trace: CFileZillaEnginePrivate::ResetOperation(66)

[matalliac]

Also fails for me. We use vsftpd on a linux server. Any clients below 3.5.3 connect fine. I too am reverting back to an older version.

[boco]

@botg: Please disclose exactly what exactly you changed, and the new preconditions for the server TLS components. I will then refer the server devs to this thread, and others can do the same.

I'll stick this thread for a week, for the time being.


Edit: I found a list of ciphers for the server I'm using. Would it be possible none of them works anymore?

Code: Select all

"RSA-RC4-MD5,RSA-3DES-SHA,RSA-AES256-SHA,DH-RSA-3DES-SHA,DHE-RSA-3DES-SHA,DH-ANON-RC4-MD5,RSA-RC4-MD5-EXPORT"

Edit2: FileZilla 3.5.2 negotiated the following cipher with my server:

Code: Select all

Cipher: 3DES-CBC, MAC: SHA1

3DES sounds pretty weak to me...

[botg]

I've removed 3DES from the allowed ciphers, along with the MD5 hash algorithm.

Edit: I found a list of ciphers for the server I'm using. Would it be possible none of them works anymore?

Code: Select all

"RSA-RC4-MD5,RSA-3DES-SHA,RSA-AES256-SHA,DH-RSA-3DES-SHA,DHE-RSA-3DES-SHA,DH-ANON-RC4-MD5,RSA-RC4-MD5-EXPORT"

All of them are insecure in my opinion. Of the above, only RSA-AES256-SHA has acceptable key strength but still isn't secure as it doesn't offer forward secrecy which is commonly established by performing a Diffie-Hellman key exchange.

You should update to a more modern server.

[Technofrood]

It seems my copy of vsftpd is using SSL Cipher DES-CBC3-SHA, is this also not secure and not allowed by FileZilla anymore?

[boco]

If you mean 3DES-CBC-SHA, that one seems to be banned now.

http://svn.filezilla-project.org/filezi ... threv=4384

[Technofrood]

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.

[boco]

This identical text is also in the zFTPServer forum:
------------------------------------------------------------

Solution for zFTPServer Suite users:

1.(A) Shut down the service part of zFTPServer.
2.(A) Open Settings.ini in the zFTPServer directory
3. Go to the [FTPS Ciphers] line. Below are the ciphers zFTP offers for negotiation.
4. Go to the end of the line listing the ciphers, and before the terminal double-quote, add:

[FTPS Ciphers]
"<List of other ciphers>,DHE-RSA-AES256-SHA,DHE-RSA-CAMELLIA256-SHA,DHE-RSA-AES128-SHA,DHE-RSA-CAMELLIA128-SHA"

5. (A) Save the file.
6. (A) Start the service again.

(A) means administrative privileges required.


The next zFTPServer version will likely have these ciphers included by default.

[tom_uk]

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.

[xeon]

While I disagree that DES-CBC3-SHA is a "weak" cipher I agree with botg's end decision to remove support for it.

This is mostly for performance reasons 3DES is one of the slowest ciphers around and does nothing but waste cpu cycles compared to superior alternatives.

My preference is always to use RC4-SHA or when possible ECDHE-RSA-RC4-SHA however not much supports ECDHE at the moment and vsftpd doesn't even support regular DHE to begin with much less ECDHE.

Using RC4-SHA in my opinion is the best choice as you get way better performance than any other cipher and it's not CBC based like everything else all while providing plenty enough protection and in some cases even more than alternatives due to it not being vulnerable to CBC based attacks.

[perfup]

I've removed 3DES from the allowed ciphers, along with the MD5 hash algorithm.

Edit: I found a list of ciphers for the server I'm using. Would it be possible none of them works anymore?

Code: Select all

"RSA-RC4-MD5,RSA-3DES-SHA,RSA-AES256-SHA,DH-RSA-3DES-SHA,DHE-RSA-3DES-SHA,DH-ANON-RC4-MD5,RSA-RC4-MD5-EXPORT"

All of them are insecure in my opinion. Of the above, only RSA-AES256-SHA has acceptable key strength but still isn't secure as it doesn't offer forward secrecy which is commonly established by performing a Diffie-Hellman key exchange.

You should update to a more modern server.

Well... I have 4 friends that are programmers and web developers like me... We all got the same response from FTP servers (private servers). Get the Portable 3.5.2 or another software, we aint upgrading shit.

So, i dont think your gonna get lot of love from ftp servers over the world. Your gonna get back to the 3.5.2 politics or get a lot of people not upgrading or using the older portable version.

And there are a bunch of ppl getting this problem, I thinkg you should reconsider. GL.
I mean, do you really think we get to decide where the client wants his files being uploaded? That we can just say... Update to a more modern server to someone who doesnt even know what a server is?

[kinsei]

While I disagree that DES-CBC3-SHA is a "weak" cipher I agree with botg's end decision to remove support for it.

This is mostly for performance reasons 3DES is one of the slowest ciphers around and does nothing but waste cpu cycles compared to superior alternatives.

My preference is always to use RC4-SHA or when possible ECDHE-RSA-RC4-SHA however not much supports ECDHE at the moment and vsftpd doesn't even support regular DHE to begin with much less ECDHE.

Using RC4-SHA in my opinion is the best choice as you get way better performance than any other cipher and it's not CBC based like everything else all while providing plenty enough protection and in some cases even more than alternatives due to it not being vulnerable to CBC based attacks.

This is a silly reason to agree with removing support for the cipher from the client. As long as you have the choice to choose your ciphers, why should you care what ciphers other users of the client prefer? Why do you agree with forcing users to either never upgrade or switch clients if they don't have control over the FTP servers that they are connecting to? What possible benefit does this provide to you personally?

As has been stated several times, this move seems to serve no purpose other than to frustrate users to no end when they cant connect to servers they had been able to connect to forever with this client.

If you want to change behavior, change the default. Don't remove all of the features that you don't like but which others find useful. The code already existed to support this. It would seem to be very easy to implement a checkbox to allow for its continued support while removing it from the program's default installation.

But I guess it's a free program so you can choose to do whatever you like. The irony of that donate button sitting in the top right of the screen is, however, most striking now; and I will be sure to never be fooled into clicking on it again after seeing the way all of the users are ignored in this way. "Yes, please donate to use so we can continue to code our own pet projects without regard for you, the one donating."

[xeon]

While I disagree that DES-CBC3-SHA is a "weak" cipher I agree with botg's end decision to remove support for it.

This is mostly for performance reasons 3DES is one of the slowest ciphers around and does nothing but waste cpu cycles compared to superior alternatives.

My preference is always to use RC4-SHA or when possible ECDHE-RSA-RC4-SHA however not much supports ECDHE at the moment and vsftpd doesn't even support regular DHE to begin with much less ECDHE.

Using RC4-SHA in my opinion is the best choice as you get way better performance than any other cipher and it's not CBC based like everything else all while providing plenty enough protection and in some cases even more than alternatives due to it not being vulnerable to CBC based attacks.

This is a silly reason to agree with removing support for the cipher from the client. As long as you have the choice to choose your ciphers, why should you care what ciphers other users of the client prefer? Why do you agree with forcing users to either never upgrade or switch clients if they don't have control over the FTP servers that they are connecting to? What possible benefit does this provide to you personally?

As has been stated several times, this move seems to serve no purpose other than to frustrate users to no end when they cant connect to servers they had been able to connect to forever with this client.

If you want to change behavior, change the default. Don't remove all of the features that you don't like but which others find useful. The code already existed to support this. It would seem to be very easy to implement a checkbox to allow for its continued support while removing it from the program's default installation.

But I guess it's a free program so you can choose to do whatever you like. The irony of that donate button sitting in the top right of the screen is, however, most striking now; and I will be sure to never be fooled into clicking on it again after seeing the way all of the users are ignored in this way. "Yes, please donate to use so we can continue to code our own pet projects without regard for you, the one donating."

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?

[kinsei]

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.