FileZilla Forums

Posted: **2008-07-29 20:24**

Server is ProFTPd 1.3.1 -- everything worked perfectly with FileZilla 3.0.11.1. After upgrading however, when attempting to connect via Explicit TLS/SSL (same settings that worked in the previous version), the following error is observed preventing a directory listing:

Error from 3.1.0

Code: Select all

Command:	PASV
Response:	227 Entering Passive Mode (198,102,62,21,237,197).
Command:	LIST
Response:	150 Opening ASCII mode data connection for file list
Error:	Could not read from transfer socket: ECONNABORTED - Connection aborted
Response:	226 Transfer complete
Error:	Failed to retrieve directory listing

Error from 3.1.0.1

Code: Select all

Command:	PASV
Response:	227 Entering Passive Mode (198,102,62,21,234,227).
Command:	LIST
Response:	150 Opening ASCII mode data connection for file list
Status:	Server did not properly shut down TLS connection
Error:	Could not read from transfer socket: ECONNABORTED - Connection aborted
Response:	226 Transfer complete
Error:	Failed to retrieve directory listing

(Initial connection and authentication works fine)

This problem occurs in 3.1.0 as well as 3.1.0.1 and the latest nightly snapshot. I thought perhaps the issue was introduced as a result of the security fix mentioned on the front page, but supposedly this fix wasn't put in place until 3.1.0.1... in any case, the ProFTPd developers do not feel their implemention of TLS/SSL is incorrect (see this thread and this post specifically.

Could a developer here comment? Is this related to the security issue, or perhaps another problem that crept in? In the meantime, we're just telling users to stick with the 3.0.11.1 release which still works fine.

Posted: **2008-07-29 20:34**

Debug level 4 output:

Code: Select all

Command:	PASV
Trace:	CTlsSocket::OnRead()
Trace:	CFtpControlSocket::OnReceive()
Response:	227 Entering Passive Mode (198,102,62,21,235,117).
Trace:	CFtpControlSocket::TransferParseResponse()
Trace:	  code = 2
Trace:	  state = 2
Trace:	CFtpControlSocket::SendNextCommand()
Trace:	CFtpControlSocket::TransferSend()
Trace:	  state = 4
Command:	LIST
Trace:	CTransferSocket::OnConnect
Trace:	CTlsSocket::Handshake()
Trace:	Skipping socket event 4, id mismatch.
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::OnSend()
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::Handshake()
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::Handshake()
Trace:	CFtpControlSocket::OnReceive()
Response:	150 Opening ASCII mode data connection for file list
Trace:	CFtpControlSocket::TransferParseResponse()
Trace:	  code = 1
Trace:	  state = 4
Trace:	CFtpControlSocket::SendNextCommand()
Trace:	CFtpControlSocket::TransferSend()
Trace:	  state = 5
Trace:	CTlsSocket::OnRead()
Trace:	CTlsSocket::Handshake()
Trace:	Handshake successful
Trace:	Cipher: AES-128-CBC, MAC: SHA1
Trace:	GnuTLS error -9: A TLS packet with unexpected length was received.
Status:	Server did not properly shut down TLS connection
Trace:	CTransferSocket::OnClose(10053)
Error:	Transfer connection interrupted: ECONNABORTED - Connection aborted
Trace:	CTransferSocket::TransferEnd(3)
Trace:	CFtpControlSocket::TransferEnd()
Trace:	CTlsSocket::OnRead()
Trace:	CFtpControlSocket::OnReceive()
Response:	226 Transfer complete
Trace:	CFtpControlSocket::TransferParseResponse()
Trace:	  code = 2
Trace:	  state = 7
Trace:	CFtpControlSocket::ResetOperation(2)
Trace:	CControlSocket::ResetOperation(2)
Trace:	CFtpControlSocket::ParseSubcommandResult(2)
Trace:	CFtpControlSocket::ListSubcommandResult()
Trace:	  state = 2
Trace:	CFtpControlSocket::ResetOperation(2)
Trace:	CControlSocket::ResetOperation(2)
Error:	Failed to retrieve directory listing

Also see this bug report. It seems to happen with the FileZilla server also perhaps?

Posted: **2008-07-29 20:50**

Status: Server did not properly shut down TLS connection

Yes this is the problem. The security advisory on the front page is about that. And it's all over the forums.

Yes, there have been reports about Filezilla Server, too. That's because Filezilla doesn't care where the FIN packet got lost/corrupted. It could be the server is sending it, but for some reason it doesn't arrive at the client.

Posted: **2008-07-29 20:53**

I'll do some more reading.

I'm just worried this is going to devolve into a blame game between server people and the FileZilla client. ProFTPd for example feels they're following the spec, and I'm sure FileZilla had good reason for doing what its doing as well......

Posted: **2008-07-29 21:04**

Alright, duh, shoulda read down further.

Go ahead and lock this if ya like. Dupe of this thread.

Posted: **2008-07-29 21:57**

Closed on request.

FileZilla Forums

SSL woes with >= 3.1.0

SSL woes with >= 3.1.0

Re: SSL woes with >= 3.1.0

Re: SSL woes with >= 3.1.0

Re: SSL woes with >= 3.1.0

Re: SSL woes with >= 3.1.0

Re: SSL woes with >= 3.1.0