Ask Slashdot: Secure FTP? 85
Tobbe Johansson asks:
"I would like to put a secure layer between
my FTP-daemon and the network. I have
searched for a program that
encrypts/decrypts the port where my FTP is
running but I have not been able to find
anything that seems to work. Can anyone help
me?"
use mc (Score:1)
Re:Another way (Score:1)
Secure FTP ? (Score:1)
SSL tunnel:
http://mike.daewoo.com.pl/computer/stunnel/
secure FTP (Score:2)
If you want everything to be safely encrypted, your choices are:
(1) Use scp (part of ssh) to do the transfers. Works like rcp, can also copy over whole directories recursively.
There are also free versions of scp out there for win and mac.
(2) Use a SSL-ified FTP server and program. (check www.ssleay.org for a link).
Problem: I don't know of any SSL FTP programs out there for win or mac
IPsec as an option (Score:2)
If they are both Linux, then look at:
http://www.flora.org/freeswan/
Not only will your FTP be encrypted, but so will
your Telnet, HTTP, and even your pings. The good
thing about this would be that you don't need any
special client or server applications.
Isn't this what SSL is for? (Score:1)
SSL/TLS FTP (Score:5)
First, go to http://www.openssl.org/ [openssl.org]. OpenSSL is based on SSLeay and is the basis for open source SSL communications in unix. You'll want to grab openssl and compile it and install it. It provides a number of useful programs including md5 & sha for generating checksums on files and a whole suite of other cipher routines.
Next visit http://www.psy.uq.oz.au/~ftp/Crypto/ [uq.oz.au] and go find an FTP server and client pair which have SSL support. There are also a few general proxy deals which can handle it with any standard FTP server.
Now there are a few ways to do authentication, you can do normal authentication or authentication based on certificate which requires a CA server (things like verisign will work if you want to shell out some cash, but you can also build your own CA).
The great thing about SSL is it can autodetect encryption support. So you can take a standard telnet server, make a few minor modifications to get it SSL capable and connect to it using SSL capable telnet client or a vanilla telnet client and it'll use the strongest security possible.
No need for silly third party daemons or special ports. Although the official TLS service ports are different from their unencrypted couterparts.
This is good if you are behind a corporate lan which doesn't like allowing anything besides telnet, ftp, and web traffic through their proxy.
--
Re:SSH can do it... (Score:2)
Re:sftp? (Score:1)
Trivial Excercise with Java (Score:1)
Should be easy to make an app in java 2 using the JCE and streams. What type of encryption do you want?
Re:.slightly off topic... (Score:1)
lftp will also do this. It also comes with a cool mirror option that will mirror a remote directory to a specified local one.
Re:UDP vs TCP in regards to FTP. (Score:1)
Zero security.
As far as this topic goes, I echo: sftp, ssh, stunnel
Kerborized FTP (Score:1)
Ssh port forwarding would probably also work, but everybody else has already suggested that so I figured I'd throw out a different option.
Re:Secure FTP: A few ways (Score:1)
Am I wrong here?
Internet Draft (Score:1)
I don't believe there is a free implementation, but the specs are there, so anyone can have a stab at it (hope they do). There are several commercial implementations of the client.
--
Re:Why does FTP still exist? (Score:1)
FTP is actually 2 connections:
-a stateless UDP for data transfer
-a stated TCP control.
By using UDP, which requires no acknowledgement of packets, FTP is significantly speedier than its retarded cousin, HTTP. I recommend you read some RFC's.
Re:secure FTP (applications for other OS's) (Score:1)
I found that secureCRT (which supports both ssh and telnet) it very nice for windows. As for mac I haven't found anything. There is also a free ssh client for windows that is just called ssh client for windows. Don't have much on that one, it hs some copy paste termial emulation probs.
Re:Why does FTP still exist? (Score:1)
As for the TLS/SSL bit... well, there you've got me. Secure transfers are indeed a must on the Net today.
WS_FTP + F-Secure SSH (Score:1)
I would like to expand on this question.
F-Secure SSH supports port forwarding but I haven't quite figured out how to forward my FTP connections through the F-Secure SSH to my WS_FTP client. Is this possible? If so, is there a HOW-TO anywhere?
Thanks in advance!
EugeneRe:.slightly off topic... (Score:2)
--
Aaron Gaudio
"The fool finds ignorance all around him.
FTP Doesn't use UDP (Score:1)
SSH can do it... (Score:3)
Re:ssh + ftp passive mode (Score:1)
ssh's own scp is a thing of beauty.
Beware of how scp2 and scp1 interact (or don't, rather), though.
~gr
Re:Why does FTP still exist? (Score:1)
HTTP cannot perform directory listings, nor can it return those directory listings in terms which a computer can understand - there's absolutely nothing in the standard for it.
FTP, on the other hand, gives out surprising little information about what the files it is giving access to are for, something that HTTP has done since 1.0. (Note: FTP can, actually, do this too, but it's not
Don't confuse FTP with HTTP - they're very different protocols, with the common feature of being able to transfer a file in a stable manner. But that's the base use of both - their feature sets diverge heavily from that point.
Back onto the point in hand, ftp://ftp.replay.com/pub/crypto/ should have all the FTP/SSL stuff you want, but it's non-standard... If you want to make it a standard, head on over to http://www.ietf.org/ and join in the fun.
Re:Why does FTP still exist? (Score:1)
I assume you mean the kind of meta-information within HTTP/1.1 headers. It does, in the 'MLST' style listings. It can contain MIME types, sizes of files, and almost any other information that you can think of. It's held in a machine readable listing, which allows for a quick and easy method of detirmining which file you want.
That's a different concept to HTTP's - giving you the file that the author of the site wants to give you - and neither is wrong, just very different.
But you're right in that neither is worse for large file transfers of a specific file. It's simply that finding that specific file may prove easier with FTP.
Re:Stanford's SRP (Score:2)
http://srp.stanford.edu/
enjoy, it works well!
Re:Why does FTP still exist? (Score:1)
----------------------
Not as silly as it sounds - zmodem over ssh (Score:1)
The major disadvantage is that it ties up your interactive connection.
Stunnel! (Score:1)
Re:IPsec as an option (Score:1)
I believe Win2K has this. I wouldn't be suprised to see a client back ported to Win9x and NT4 once Win2K is out.
--
Re:Why does FTP still exist? (Score:1)
I also find it odd that people find HTTP less reliable than FTP for downloading large files. It really shouldn't make any difference. (Of course, if you've got an unreliable connection, FTP is better assuming both the server and client support resumption of interrupted transfers.)
cjs
Re:Kerborized FTP : Its there (Score:1)
Definitely lot less trouble than ssh (if kerberos is up
CIPE - Crypto IP Encapsulation (Score:3)
"This is an ongoing project to build encrypting IP routers. The protocol used is as lightweight as possible. It is designed for passing encrypted packets between prearranged routers in the form of UDP packets. This is not as flexible as IPSEC but it is enough for the original intended purpose: securely connecting subnets over an insecure transit network. The implementations mentioned below are actually in use in such an application."
The newest version of CIPE is available on
http://sites.inka.de/~bigred/devel/cip e.html [sites.inka.de]
or ftp://sites.inka.de/sites/bigred/devel/cipe.html
It also works well for getting around those pesky universtity firewalls.
Re:Another way (Score:1)
NCFTP (Score:1)
BUT, ncftp uses the ls -R (i think) command to retrieve the directory listing. That is, it gets the list of the entire tree, then downloads it all. WSFTP gets it one dir at a time, and can work on pretty much any ftp, unlike ncftp. NCFTP also can't handle any kind of ftp servers that return unusual stuff in the directory listings..
sendfile (for something completely different) (Score:3)
Something to give a shot for those of you wanting to give your friend, who's too lazy/paranoid/poor to set up an ftp server, a file.
Re:secure FTP (Score:1)
thanks.
Re:NiftyTelnet SSH (Score:1)
Re:SSH can do it... (Score:1)
Re:secure FTP (applications for other OS's) (Score:1)
scp (Score:1)
Stanford's SRP (Score:2)
proxy/forward/bounce rather than encrypt? (Score:1)
On the other hand, ssh/scp rocks. First choice if you can do it.
Secure FTP (Score:1)
Re:.slightly off topic... (Score:1)
It is far better than other ftp clients I have tried.
sftp? (Score:1)
Re:Internet Draft (Score:2)
Re:WS_FTP + F-Secure SSH (Score:1)
GSSFTP (Score:2)
Re:Why does FTP still exist? (Score:1)
Um, I recommend you ACTUALLY read some RFCs. Such as rfc 959, File Transfer Protocol.
Here's a link to it. [ic.ac.uk]
Nowhere in the text do the letters UDP even occur in order.
Furthermore, under section 3.3: Data connection management, we find the following:
Reuse of the Data Connection: When using the stream mode of data transfer the end of the file must be indicated by closing the connection. This causes a problem if multiple files are to be transfered in the session, due to need for TCP to hold the connection record for a time out period to guarantee the reliable communication. Thus the connection can not be reopened at once.
(Emphasis added)
Please make sure you know what you're talking about next time before you tell others they don't.
Re:Man-in-the-middle (Score:1)
The problem is that the ssh public-key exchange is still open to a nice man-in-the-middle attack. For example, if I'm using a kiosk terminal with ssh to connect to my host back at Stanford, even if we assume that the kiosk itself is not tampered with, someone can spoof DNS easily enough and have the kiosk connect to the attacker's host, which gladly gives its own public key to the kiosk, opens a connection to the real host, and patches all the session traffic through, capturing the password and the entire session without the user's knowledge.
Re:Secure FTP: A few ways (Score:1)
and "passive" mode FTP is that in passive
mode, the client opens the data connection
to the server, instead of vise-versa.
The data connection is still a separate
stream, and happens between random ports.
Passive is good for things like NAT firewalls,
though, because it allows all connections to
remain outbound instead of requiring an
inbound connection. But it will still bypass
your port forwarding.
Secure FTP: A few ways (Score:5)
http://www.uni-karlsruhe.de/~ig25/ssh-faq/ [uni-karlsruhe.de]
As it points out, this will leave the data connection open to sniffing/hijacking. If you only care about the integrity of the files you transfer, then verifying against (securely obtained) md5 checksums should do the trick. If you want to encrypt the datastream, you'll need to be a bit more fancy.
If it's possible, consider the use of 'scp' instead of ftp; you'll get protection of both control and data, since it's built into ssh.
Another option (if you control the clients as well) is to use ssh2's "sftp" client. Beware the licensing issues with ssh2, however.
If you really trust the clients, it's also quite easy to set up a VPN between the client and server, and then FTP directly. The ways to go about this depend on the OS you're using, so I'll leave it as an exercise to the reader.
Re:.slightly off topic... (Score:1)
Re:Sorry, you're wrong (Score:1)
Re:WS_FTP + F-Secure SSH (Score:1)
TeraTerm is a free Windows telnet client that has both Z-Modem and SSH support. http://www.zip.com.au/~roca/ttssh.html
I have been unable to secure WS_FTP using port forwarding with Igaly's SSH client http://www.doc.ic.ac.uk/~ci2/ssh/ because the data port changes on the Windows side with each connection...
ssh + ftp passive mode (Score:3)