"GnuTLS error -12: A TLS fatal alert has been received." + "no shared cipher"

[kempi29]

GnuTLS error -12: A TLS fatal alert has been received.

in new version 3.5.3 win client, old version 3.5.2 works just fine.
Server UNIX.

[David Anderson]

Same problem here.

Have run FileZilla 3.5.3 on Windows 7 and on Linux under Wine. Trying to log in to a server via explicit TLS. Server is running CentOS 5 latest update of vsftpd (vsftpd-2.0.5-21.el5).

FileZilla 3.5.2 logs in successfully. 3.5.3 returns:

"Error: GnuTLS error -12: A TLS fatal alert has been received.
Error: Could not connect to server"

[bratkartoffel]

Same here, some more information:

Status:	Resolving address of xxxxxx.de
Status:	Connecting to xx.xx.xx.xx:21...
Status:	Connection established, waiting for welcome message...
Trace:	CFtpControlSocket::OnReceive()
Response:	220 Welcome to xxxxxx.de FTP service.
Trace:	CFtpControlSocket::SendNextCommand()
Command:	AUTH TLS
Trace:	CFtpControlSocket::OnReceive()
Response:	234 Proceed with negotiation.
Status:	Initializing TLS...
Trace:	CTlsSocket::Handshake()
Trace:	CTlsSocket::ContinueHandshake()
Trace:	CTlsSocket::OnSend()
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::ContinueHandshake()
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::ContinueHandshake()
Trace:	CTlsSocket::Failure(-12, 10053)
Trace:	GnuTLS alert 40: Handshake failed
Error:	GnuTLS error -12: A TLS fatal alert has been received.
Trace:	CRealControlSocket::OnClose(10053)
Trace:	CControlSocket::DoClose(64)
Trace:	CFtpControlSocket::ResetOperation(66)
Trace:	CControlSocket::ResetOperation(66)
Error:	Could not connect to server
Trace:	CFileZillaEnginePrivate::ResetOperation(66)
Status:	Waiting to retry...
Trace:	CControlSocket::DoClose(64)
Trace:	CControlSocket::DoClose(64)
Error:	Connection attempt interrupted by user

[Lynch]

Same problem on windows XP with Filezilla 3.5.3 Trying to login to VSFTPD 2.0.7 server on debian box with TLS explicit.

Here is the vsftpd server log:

Jan 10 12:08:24 xxxxxxx vsftpd: Tue Jan 10 12:08:24 2012 [pid 6862] CONNECT: Client "xxx.xxx.xxx.xxx"
Jan 10 12:08:24 xxxxxxx vsftpd: Tue Jan 10 12:08:24 2012 [pid 6862] FTP response: Client "xxx.xxx.xxx.xxx", "220 FTP:"
Jan 10 12:08:24 xxxxxxx vsftpd: Tue Jan 10 12:08:24 2012 [pid 6862] FTP command: Client "xxx.xxx.xxx.xxx", "AUTH TLS"
Jan 10 12:08:24 xxxxxxx vsftpd: Tue Jan 10 12:08:24 2012 [pid 6862] FTP response: Client "xxx.xxx.xxx.xxx", "234 Proceed with negotiation."
Jan 10 12:08:25 xxxxxxx vsftpd: Tue Jan 10 12:08:25 2012 [pid 6862] DEBUG: Client "xxx.xxx.xxx.xxx", "SSL_accept failed: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher"

FileZilla 3.5.0 logs in successfully

[brandon barker]

Same issue here. Connected with FTP over TLS just fine in 3.5.2, and in 3.5.3 cannot connect. Verified by downgrading FileZilla back to 3.5.2, and the same saved connection was able to connect just fine.
Local Machine: Windows 7 SP1
Server: Unix AIX 6.1
Status: Connection established, initializing TLS...
Trace: CTlsSocket::Handshake()
Trace: CTlsSocket::ContinueHandshake()
Trace: CTlsSocket::OnSend()
Trace: CTlsSocket::OnRead()
Trace: CTlsSocket::ContinueHandshake()
Trace: CTlsSocket::OnRead()
Trace: CTlsSocket::ContinueHandshake()
Trace: CTlsSocket::Failure(-12, 10053)
Trace: GnuTLS alert 40: Handshake failed
Error: GnuTLS error -12: A TLS fatal alert has been received.
Trace: CRealControlSocket::OnClose(10053)
Trace: CControlSocket::DoClose(64)
Trace: CFtpControlSocket::ResetOperation(66)
Trace: CControlSocket::ResetOperation(66)
Error: Could not connect to server
Trace: CFileZillaEnginePrivate::ResetOperation(66)
Status: Waiting to retry...

[jeremy dyson]

Same issue, windows 7 with filezilla 3.5.3 worked fine before update about 5 minutes ago.

[h17117]

19:37:09	Status:	Resolving address of www.regarddepend.com
19:37:09	Status:	Connecting to 69.64.34.192:21...
19:37:10	Status:	Connection established, waiting for welcome message...
19:37:10	Response:	220 (vsFTPd 2.0.5)
19:37:10	Command:	AUTH TLS
19:37:10	Response:	234 Proceed with negotiation.
19:37:10	Status:	Initializing TLS...
19:37:10	Error:	GnuTLS error -12: A TLS fatal alert has been received.
19:37:10	Error:	Could not connect to server
19:37:10	Status:	Waiting to retry...
19:37:15	Status:	Delaying connection for 1 second due to previously failed connection attempt...

Server - vsftp, on centOS5

[Mircea Vutcovici]

The problem is an incompatibility in the cipher suite that FileZilla is supporting and the cipher suite configured by default on vsftpd.

In the wireshark capture you can see:

Response arg: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

The default is DES-CBC3-SHA which seems that is not supported anymore by FileZilla

[bratkartoffel]

The workaround suggested by mircea.vutcovici works, but not all users have access to the ftp-servers configuration.

I suggest to add a more detailed error message in this case, the "GnuTLS error -12" is not really self-explanatory.

[Mircea Vutcovici]

Replying to mircea.vutcovici:

The problem is an incompatibility in the cipher suite that FileZilla is supporting and the cipher suite configured by default on vsftpd.

In the wireshark capture you can see:

Response arg: error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

The default is DES-CBC3-SHA which seems that is not supported anymore by FileZilla

OS: Ubuntu 8.04.4 LTS 32 bit
vsftpd: 2.0.6-1ubuntu1.2
libssl0.9.8: 0.9.8g-4ubuntu3.13

[harry]

I have the same prob here. I have win7 on my machine connecting to ruTorrent... Error: GnuTLS error -12: A TLS fatal alert has been received. All was fine before the update

[Michael Davis]

I have the same problem. I only have a couple servers I use that require TLS (all with Core Commerce), but I can no longer access them.

Unfortunately their support is recommending changing FTP client's. I would prefer not to do that, but is there any plan to address this or do we just have to move on if server side fixes are not available to us?

[muntain]

Same problem with vsftpd 2.0.6 on a red hat
Filezilla Client 3.5.3 can't login
3.5.2 it's ok

[bratkartoffel]

Could be fixed with Revision 4390 (​http://svn.filezilla-project.org/filezilla?revision=4390&view=revision), will try this revision today.

[calimano]

@bratkartoffel, I don't see how that will resolve your issue seeing as vsftpd doesn't even support DH cipher suites.

Your issue and everyone elses is that your vsftpd configuration defaults to using 3DES as the cipher and filezilla client no longer supports it.

The only way to resolve this is by changing the cipher to something else.

[blaubeerpfannkuchen]

same problem 3.5.3 (3.5.2 fine) by loggin in from Win7+XP onto a Seagate NAS 110 server. Problem with NAS server: it is preconfigured Unix with a web GUI. It is not intented to change settings there as root.

[calimano]

@blaubeerpfannkuchen, It's possible to change the configuration file on the Seagate NAS 110 just google for instructions.

[Marketto]

Same problem here in new version 3.5.3 win client, old version 3.5.2 works just fine.

Replying to kempi29:

GnuTLS error -12: A TLS fatal alert has been received.

in new version 3.5.3 win client, old version 3.5.2 works just fine.
Server UNIX.

[nyama]

I am afraid to say that many users go away from FileZilla due to this problem.

[Jouni Järvinen]

Exactly same error here, same FZ, XP Pro SP3, Debian 6, ProFTPD 1.3.3a. I've not tried using FTPS with implicit SSL/TLS, just excplicit cuz it uses same port as FTP.

Debug trace:

16:47:50	Status:	Connecting to xxx.xxx.xxx.xxx:21...
16:47:50	Status:	Connection established, waiting for welcome message...
16:47:50	Trace:	CFtpControlSocket::OnReceive()
16:47:50	Response:	220 ProFTPD 1.3.3a Server (xxxxxxxxxx) [::XXXX:xxx.xxx.xxx.xxx]
16:47:50	Trace:	CFtpControlSocket::SendNextCommand()
16:47:50	Command:	AUTH TLS
16:47:50	Trace:	CFtpControlSocket::OnReceive()
16:47:50	Response:	234 AUTH TLS successful
16:47:50	Status:	Initializing TLS...
16:47:50	Trace:	CTlsSocket::Handshake()
16:47:50	Trace:	CTlsSocket::ContinueHandshake()
16:47:50	Trace:	CTlsSocket::OnSend()
16:47:50	Trace:	CTlsSocket::OnRead()
16:47:50	Trace:	CTlsSocket::ContinueHandshake()
16:47:50	Trace:	CTlsSocket::OnRead()
16:47:50	Trace:	CTlsSocket::ContinueHandshake()
16:47:50	Trace:	CTlsSocket::Failure(-12, 10053)
16:47:50	Trace:	GnuTLS alert 40: Handshake failed
16:47:50	Error:	GnuTLS error -12: A TLS fatal alert has been received.
16:47:50	Trace:	CRealControlSocket::OnClose(10053)
16:47:50	Trace:	CControlSocket::DoClose(64)
16:47:50	Trace:	CFtpControlSocket::ResetOperation(66)
16:47:50	Trace:	CControlSocket::ResetOperation(66)
16:47:50	Error:	Could not connect to server
16:47:50	Trace:	CFileZillaEnginePrivate::ResetOperation(66)

[Augustus Carter]

We are encountering the same problem using FileZilla 3.5.3 on Windows XP and Windows 7.

Status: Connecting to ...
Status: Connection established, waiting for welcome mesasge...
Response: ...
Command: AUTH TLS
Response: 234 Proceed with negotiation.
Status: Initializing TLS...
Error: GnuTLS error -12: A TLS fatal alert has been received.
Error: Could not connect to server
Status: Waiting to retry...

We had to go back to FileZilla 3.5.2 as a work-around.

[bratkartoffel]

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

This is a workaround on server-side, it's working for me like a charm. But still not happy with it, but it seems this "bug" will remain in filezilla as vsftpd is a little out-dated regarding ssl-ciphers and -strength.

Regards,
Simon

[Jouni Järvinen]

Replying to bratkartoffel:

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

What about ProFTPD ?

Same issue, tested on

• Linux Mint 10 which bases on Ubuntu 10.10
• Ubuntu 11.10

Not sure about what to put as 'Operating system type'.

[Kbh]

Simon this does not work for me on windows 7. Still getting errors. Are you modifying anything else ?

/Kbh

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

This is a workaround on server-side, it's working for me like a charm. But still not happy with it, but it seems this "bug" will remain in filezilla as vsftpd is a little out-dated regarding ssl-ciphers and -strength.
Regards,
Simon

---

Replying to rautamiekka:

Replying to bratkartoffel:

The solution is to add to the /etc/vsftpd.conf :

ssl_ciphers=HIGH

​Eventbureau København What about ProFTPD ?

Same issue, tested on

• Linux Mint 10 which bases on Ubuntu 10.10
• Ubuntu 11.10

Not sure about what to put as 'Operating system type'.

[bratkartoffel]

Hi Kbh,

as i said this is a workaround you can set on your server. This implies that you use vsftpd as ftp-software there. Have you restarted vsftdp after changing the setting?
e.g. on ubuntu / debian execute:

/etc/init.d/vsftpd restart

Regards,
Simon

[Kbh]

Nope, and doing that worked :)

Thanks !
/Kbh

Replying to bratkartoffel:

Hi Kbh,

as i said this is a workaround you can set on your server. This implies that you use vsftpd as ftp-software there. Have you restarted vsftdp after changing the setting?
e.g. on ubuntu / debian execute:

/etc/init.d/vsftpd restart

Regards,
Simon

[gar]

This is a strange idea of reasonable behavior for a production FTP client: breaking compatibility with huge swaths of FTP servers, and then ignoring the problem for half a year. Off to WinSCP...

[Søren Juul]

The

set_cipers=HIGH

trick for vsftpd seems to only be working when

chroot_local_user=YES

is not set (or set to NO)

[Alexander Schuch]

Here another summary from #8322:

"HISTORY:
3.6.0.1 - does not connect
3.6.0 - worked fine!
3.5.3 - does not connect
3.5.2 (and older) - worked fine!"

The proposed "fix" is to use strong ciphers (as mentioned in previous posts) or not use encryption at all.

[Vlado]

Replying to zpon:

trick for vsftpd seems to only be working when

chroot_local_user=YES

is not set (or set to NO)

ssl_ciphers=HIGH works for me despite the fact that I have chroot_local_user=YES!
vsftpd-2.2.2-11.el6.i686
FileZilla_3.6.0.2_win32-setup.exe
CentOS release 6.3