Subject: Ftp-WG: FTP over SSL

From: "Robert Oslin" <[email-masked]>
Date: Tue, 7 Aug 2001 21:05:45 -0500

approved: zacaroo

Hi, I've been following this discussion. CuteFTP Pro just closes the socket,
both for normal FTP and TLS sessions. I'll check into proper closing of TLS
for version 2.0 of Pro, due out in beta soon. Another thing fixed already,
is the ability to perform PBSZ 0 / PROT P, and PBSZ 0 / PROT C for encrypted
and clear data channels. Currently it only supports encrypted data channel
via implicit or explicit SSL/TLS connection methods.
I also have a couple of new (read proprietary) ftp commands which will be
added to Pro 2.0 and our server. I'll pass them by the group soon to get
your feedback, and also to inquire on whether they are worthy of
consideration for future ftp drafts.

Robert Oslin
Chief Architect & CuteFTP Pro program manager
GlobalSCAPE, Inc.

-----Original Message-----
From: ftp-wg-owner [mailto:[email-masked]]On Behalf Of Alun
Jones
Sent: 07 August, 2001 11:23 AM
To: FTPEXT Working Group
Subject: Ftp-WG: FTP over SSL

At 09:56 AM 8/7/2001, you wrote:
>The Data connection should be terminated.  The fact that the Data
>channel has been interrupted does not imply in any way that the
>security of the Control channel has been violated.

Could you clarify - does this mean that you think if a sender gracefully
closes the socket without first closing the TLS connection, the receiver
should treat this as a successful completion of the transfer?  Or not?

> > I do agree that it might be nice to point out that TLS requires this
> > behaviour and implementations could be considered broken if they don't
> > send close_notifys.
>
>Although, unnecessary.

There's at least one implementation out there - specifically, CuteFTP, that
closes the socket without shutting down the TLS session on that
socket.  When I have time, I'll be getting onto them about this
behaviour.  However, it may be worth putting in a note as to whether it
really matters for the purposes of FTP as to whether the client shuts down
TLS properly, or just closes the socket gracefully underneath it.

There are two RFCs at question here that may not be adequately read in
depth - the first is venereal old RFC 959, with its concept of closing the
socket to indicate end of transfer in stream mode.  The second is whatever
TLS RFC says that a TLS shutdown must be performed prior to closure.  Now,
seriously, while you and I may have bothered to read through that RFC, how
many FTP app authors are going to do more than read the SDK documentation
for whatever SSL library they're using?

Alun.
~~~~
P.S. Sorry I haven't raised anything about the FTP / TLS draft until now -
I haven't managed to get my own implementation working until recently, and
I didn't want to post while my own understanding was apparently in such a
seriously poor situation.

--
Texas Imperial Software   | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place   | http://www.wftpd.com or email [email-masked]
Cedar Park TX 78613-1419  | VISA/MC accepted.  NT-based sites, be sure to
Fax/Voice +1(512)378-3246 | read details of WFTPD Pro for NT.

===================END FORWARDED MESSAGE===================

Paul Hethmon
[email-masked]
http://www.hethmon.com