Hi List,

my Users report problems with new filezilla 3.1 and proftpd 1.3.1. case is
as follows:

In Filezilla you can connect by Type "ftp over explicit tls/ssl" If this is
selected Connection cant be established.
My Servercert. is ok and already accepted by client. This is filezillalog:


Status: Resolving address of server.name
Status: Connecting to ip.add.re.ss:21...
Status: Connection established, waiting for welcome message...
Response: 220 FTP on server.name ready
Command: AUTH TLS
Response: 234 AUTH TLS successful
Status: Initializing TLS...
Status: Verifying certificate...
Command: USER user
Status: TLS/SSL connection established.
Response: 331 Password required for user
Command: PASS *********
Response: 230 User user logged in
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: MDTM
Response: AUTH TLS
Response: PBSZ
Response: PROT
Response: REST STREAM
Response: SIZE
Response: 211 End
Command: PBSZ 0
Response: 200 PBSZ 0 successful
Command: PROT P
Response: 200 Protection set to Private
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/" is the current directory
Command: TYPE I
Response: 200 Type set to I
Command: PASV
Response: 227 Entering Passive Mode (ip,ip,ip,ip,195,95).
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


I tried to catch something with proftpd -nd10 but there was nothing
something special.

proftpd 1.3.1
This is my configureline:

../configure --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --with-modules=mod_tls:mod_clamav:mod_sql:mod_sql_mysql:m od_quotatab:mod_quotatab_sql:mod_ifsession
--with-includes=/usr/include/mysql --with-libraries=/usr/lib/mysql

Found a discussion in filezilla forum. It seems that new filezilla has a
problem with a lot of ftp-servers.
http://forum.filezilla-project.org/v...lit=tls#p27016

Is this a bug in servers or filezilla related?

Thanks a lot
Andre




-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

On Tue, Jul 29, 2008 at 12:25:28AM -0700, Andre Hübner wrote:
> Hi List,
>
> my Users report problems with new filezilla 3.1 and proftpd 1.3.1.
> case is as follows:
>
> In Filezilla you can connect by Type "ftp over explicit tls/ssl" If
> this is selected Connection cant be established. My Servercert. is
> ok and already accepted by client. This is filezillalog:

I get the same results as you using FileZilla >= 3.1. I just
downgraded to 3.0.11.1 and everything works fine again. Looks like
it's on the FileZilla side.

Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

On Tue, Jul 29, 2008 at 11:35:48AM -0700, Jorge Bastos wrote:
> There's already a 3.1.0.1 that i think that resolves that i think.

Tried it, no dice. Also tried the latest nightly and no go. I'm
beginning to think this might actually be a ProFTPd issue... see this:

http://filezilla-project.org/index.php

The 2008-07-24 Security Advisory:

"FileZilla 3.1.0.1 fixes a vulnerability regarding the way some
errors are handled on SSL/TLS secured data transfers.

If the data connection of a transfer gets closed, FileZilla did not
check if the server performed an orderly TLS shutdown.

Impact An attacker could send spoofed FIN packets to the client. Even
though GnuTLS detects this with GNUTLS_E_UNEXPECTED_PACKET_LENGTH,
FileZilla did not record a transfer failure in all cases.

Unfortunately not all servers perform an orderly SSL/TLS shutdown.
Since this cannot be distinguished from an attack, FileZilla will not
be able to download listings or files from such servers.

Affected versions All versions prior to 3.1.0.1 are affected. This
vulnerability has been fixed in 3.1.0.1"

Can a developer comment on the above? Would ProFTPd fall into this
camp of servers not performing an ordlerly SSL/TLS shutdown?

I've just confirmed myself that this happens on 3.1.0 which purportedly
did *not* have the fix listed above, so ... a little strange.

I'll poke the FileZilla people.

Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

> Can a developer comment on the above? Would ProFTPd fall into this
> camp of servers not performing an ordlerly SSL/TLS shutdown?

It's not a question of "orderly shutdowns" so much as a matter of
confusion, all over the map, in both FTP client and server
implementations. ProFTPD's mod_tls followed the FTPS RFC to the letter;
sadly, not all FTPS clients did the same, nor did all FTPS servers. There
is no way, in the FTPS RFC, to communicate (from client to server or vice
versa) whether a "active" (i.e. fully bi-directional) or a "passive" SSL
session shutdown is expected by both sides. If the client and server have
mismatched assumptions, things can get weird.

This issue can also be caused by different handlings of the CCC command
(which some FTPS clients use, and some don't).

In short, it's a mess.

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Education is an admirable thing, but it is well to remember from time
to time that nothing that is worth knowing can be taught.

-Oscar Wilde

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

On Tue, Jul 29, 2008 at 11:59:10AM -0700, TJ Saunders wrote:
>
> > Can a developer comment on the above? Would ProFTPd fall into this
> > camp of servers not performing an ordlerly SSL/TLS shutdown?
>
> It's not a question of "orderly shutdowns" so much as a matter of
> confusion, all over the map, in both FTP client and server
> implementations. ProFTPD's mod_tls followed the FTPS RFC to the letter;
> sadly, not all FTPS clients did the same, nor did all FTPS servers. There
> is no way, in the FTPS RFC, to communicate (from client to server or vice
> versa) whether a "active" (i.e. fully bi-directional) or a "passive" SSL
> session shutdown is expected by both sides. If the client and server have
> mismatched assumptions, things can get weird.
>
> This issue can also be caused by different handlings of the CCC command
> (which some FTPS clients use, and some don't).
>
> In short, it's a mess.

Hehe, so we could have a situation where FileZilla says it's the
server's fault and we say it's their fault. Awesome.

Well at least the older version works so we can tell clients to use
that; but we'll see what the devs over there have to say.

Thanks,
Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

For those interested in jumping into make some noise on this issue:

http://sourceforge.net/tracker/index...58&atid=887596
http://forum.filezilla-project.org/v...php?f=2&t=7559

Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

On Tue, Jul 29, 2008 at 11:59:10AM -0700, TJ Saunders wrote:
>
> > Can a developer comment on the above? Would ProFTPd fall into this
> > camp of servers not performing an ordlerly SSL/TLS shutdown?
>
> It's not a question of "orderly shutdowns" so much as a matter of
> confusion, all over the map, in both FTP client and server
> implementations. ProFTPD's mod_tls followed the FTPS RFC to the letter;
> sadly, not all FTPS clients did the same, nor did all FTPS servers. There
> is no way, in the FTPS RFC, to communicate (from client to server or vice
> versa) whether a "active" (i.e. fully bi-directional) or a "passive" SSL
> session shutdown is expected by both sides. If the client and server have
> mismatched assumptions, things can get weird.
>
> This issue can also be caused by different handlings of the CCC command
> (which some FTPS clients use, and some don't).
>
> In short, it's a mess.

See this thread:

http://forum.filezilla-project.org/v...php?f=2&t=7465

Links to (on page 2):

http://tools.ietf.org/html/rfc4346#page-27
http://rfc.net/rfc4217.html#p21

Any thoughts on this?

Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

> Links to (on page 2):
>
> http://tools.ietf.org/html/rfc4346#page-27
> http://rfc.net/rfc4217.html#p21
>
> Any thoughts on this?

Now that's interesting. Section 12.6 of RFC 4217 (FTP over SSL/TLS), for
data connections, shows a "passive" shutdown of the SSL session, i.e. the
client shuts down the session (sending a 'close_notify' to the server);
the server does not reply with its own 'close_notify' alert.

_However_, Section 12.3, for the control connection, uses an _active_
shutdown (both client and server send their 'close_notify' alerts) when
the CCC command is used.

Which means, effectively, that the SSL session shutdown behavior is not
consistent; some behaviors lead to an active (bi-directional) shutdown,
some do not. No wonder implementations get this wrong (mod_tls gets it
wrong, as it tries to use the same shutdown sequence for all connections,
be they control, data, or CCC-cleared).

TJ

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Histories make men wise; poets, witty; the mathematics, subtle; natural
philosophy, deep; moral, grave; logic and rhetoric, able to contend.

-Francis Bacon

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

On Tue, Jul 29, 2008 at 02:13:50PM -0700, TJ Saunders wrote:
>
> > Links to (on page 2):
> >
> > http://tools.ietf.org/html/rfc4346#page-27
> > http://rfc.net/rfc4217.html#p21
> >
> > Any thoughts on this?
>
> Now that's interesting. Section 12.6 of RFC 4217 (FTP over SSL/TLS), for
> data connections, shows a "passive" shutdown of the SSL session, i.e. the
> client shuts down the session (sending a 'close_notify' to the server);
> the server does not reply with its own 'close_notify' alert.
>
> _However_, Section 12.3, for the control connection, uses an _active_
> shutdown (both client and server send their 'close_notify' alerts) when
> the CCC command is used.
>
> Which means, effectively, that the SSL session shutdown behavior is not
> consistent; some behaviors lead to an active (bi-directional) shutdown,
> some do not. No wonder implementations get this wrong (mod_tls gets it
> wrong, as it tries to use the same shutdown sequence for all connections,
> be they control, data, or CCC-cleared).

So, in my particular situations (client is FileZilla, server ProFTPd,
no CCC is in-use), it appears that the server drops the connection
(FileZilla debug output):

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

Is this correct, and should it be allowed per section 12.6? Can this
behavior be (easily) adjusted to send a notify to the client and wait
for an ack?

Sadly, Wireshark isn't decrypting my TLSv1 as FTP currently...

Ray

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.p...r_id=100&url=/
_______________________________________________
ProFTPD Users List
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html