Date: Wed, 13 Jun 2001 12:59:34 -0400 From: "Antoine Beaupre (LMC)" <Antoine.Beaupre@ericsson.ca> To: freebsd-security@FreeBSD.ORG Subject: Re: OT: FTP almost gone now? (was: Re: IPFW almost works now.) Message-ID: <3B279BF6.7000601@lmc.ericsson.se> References: <200106131442.f5DEgNB10141@cwsys.cwsent.com> <3B278030.3020305@lmc.ericsson.se> <20010613111421.A777@mushhaven.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Don't get mad, jamie. :) I think most people actually *do* agree with you. But read on... Jamie Norwood wrote: > On Wed, Jun 13, 2001 at 11:01:04AM -0400, Antoine Beaupre (LMC) wrote: > >>Cy Schubert - ITSD Open Systems Group wrote: >> >>>On virtually every mailing list I'm on I've been advocating the >>>deprecation of FTP, only to get flamed by advocates of FTP. The reason >>>FTP is still used is because people want to use it. Until the majority >>>can be educated (convinced) it will continue to be used. Code (CGI >>>scripts, etc.) to perform uploads would be the start of the demise of >>>FTP. > > My main issue is that noone has yet given me a good reason WHY FTP should > be depreciated. All I keep hearing is most people saying 'Because HTTP > is better, though it needs to be fixed to do what FTP does', and a few > feeble cries of 'It's more secure to just have one service doing both, > and since Apache is more secure than FTP (Assuming, of course, you use > it in stock form and don't turn anything special on!), we should drop > FTP!'. I think the two main points are: - ftp uses 2 data connections which breaks the "transport model" or whatever you want to call it where the application layer (FTP protocol) must not deal with the transport layer (TCP ports). In HTTP, all transactions are on the same port. In FTP, the ports are negociated. This sucks. - There is no generally available SSL wrapper that allows secure communication of passwords over FTP. I never mentionned the points you quoted and I don't think they're really worth considering. :) > Noone has addressed my concerns at all, and seem to mostly ignore them. > Just to be inflamatory about it, it is a common tactic when people are > presented with an argument they don't know how to counter, to just ignore > it. I don't think I followed this behavior. > My main concern is the facts that, first off, HTTP doesn't, in most of it's > current incarnations (Both client, and server), have an easy and sane way > to handle uploading files, securely or otherwise. Agreed. > My secondary concern is ease of use. FTP is extremely easy to use, and > powerful at the same time. It has many well-written text-based applications > for it's use. HTTP has Lynx and Links, neither of which is adequet. Both > rely on having high-quality terminal emulation with no quirks, a rare > thing. I can pull up 'ftp' on any client, anywhere, and not have to worry > that curses/ncurses/xterm/whatever will not like some of it's code. I've > yet to see Lynx not look bad, and Links isn't much better. FTP == old == known and widely, well implemented. Also the fact that the protocol is "simple" compared to HTTP helps a lot. Agreed again. However, by "ease of use"... I'm not sure everyone can successfully use (eg) the Windows FTP client if they never did before. It can be tricky. Of course this is when we talk about text-only apps. When you fallback on GUIs, it's all leveled out. It depends on the availability of netscrape/exploder/aol-machin. > Tertiarily, there is the concept of statefulness. HTTP is stateless, which > is well and good for people behind firewalls and such, but FTP is stateful. > This allows us to be MUCH more interactive with the server. Agreed again. There is, however, a workaround available for HTTP: keep-alive connections. It is still not stateful though. > HTTP is nice, for what it does. It is a good 'Hyper Text Tansfer Protocol'. That is what I meant when talking about the "dir" (or "ls") workaround for HTTP. :) > And FTP is a good 'File Transfer Protocol'. Yes, HTTP can transfer files, > but it is not a suitable replacement for FTP. No. But it *could* replace it, if FTP would die off. > And I have, again, not heard > anyone who is advocating ditching FTP give any realistic and practical > reason why FTP is so evil. FTP does what it does very well, and should > be allowed to continue to do so. Yes. The only thing that really annoys me with ftp are the clear-text passwords flying around. But I guess that HTTP without SSL wouldn't solve it either. It all orbits around SFTP. And I fear that SSH implementation is way too permissive and/or complex to structure an FTP-like service. SSH is also not widely known and implemented as FTP. Long live FTP. ;) BTW, the charm for me would be a protocol that encrypts the control session (ie where the usernames and passwords are sent). Encryption of the data session we can do without. Is there anything like this? Let's kill this thread already. Respond via private mail. A. -- La sémantique est la gravité de l'abstraction. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3B279BF6.7000601>