NinjaMuffin wrote:I can't see you mentioning FTP over SSL in your latest post...so how does that in your view compare to FTP over SSH? Does FTP over SSL also open up a whole bunch of ports etc?
similar, with similar problems as normal ftp. Although, PXR has it wrong. SSL is negotiated BEFORE commands are sent, or its not SSL. SSL was designed for transparency for sockets, a simple replace of function names and you are done. If its AFTER, then ftp would have had to been reengineered. This is why sftp has a different port (not 21, but 115). Now as to performance issues, not 100% sure, i know ftp over ssl encrypts the command channel, this is so things like username and password are encrypted, but i'm not sure if encrypts all the data channels, or maybe it only encrypts the channel if its in "ASCII" mode, i'd have to go look it up. IF so, then ftp over ssl would be faster in file transfers than ftp over ssh, because EVERYTHING is encrypted in ssh, this requires more CPU on each end.
NinjaMuffin wrote:To perhaps easier understand the specifics of my problem, I'm on a Windows machine which will be the "server". Users are on Windows and Mac so both will have be available as clients.
This is even WORSE, because ftp was never designed for windows systems, and all the windows ones i know EMULATE a unix directory for ftp gui client compatibilty, but there is no STANDARD or LAW, that says the directory listings have to be in any particular format. Directory listing are just a file transfer of a text file, so it can be in ANY format the server deems it to be in. This is why some clients have problems with other servers. Yet Another Reason why ftp is terrible.
PXR wrote:If we ignore the fact that sockets can be binded to a specific ip-address, how big of a chance is it that this actually happens? If it's gonna work, the "hacker" has to (probably) hammer multiple ports on the server under a longer period to find the one that is open for data-transfer, in say, like the time of zero to one second before the real client "grabs the slot". Such hammering could easily be stopped automatically by a firewall. So unless the "hacker" knows what port and socket to connect to or actually got the same ip-address as the client, I don't think it's really possible.
Your first comment has no bearing on this. BINDING to an ip address is only for ip addresses of attached adapters, NOT an incoming socket's ip address. This chance is pretty high nowadays, thousands, if not more, "hackers" are using port scanners, and ones that are automated, and store data from connected sockets for analysis later.
PXR wrote:When I tested some while ago (with WinSCP) to transfer several gigabytes of data via LAN (100Mbps), I got speeds of about 1MBps - not acceptable. Later I tried transfering with standard SSL-FTP, the speed bursted to 10-11MBps. I don't know, maybe I did something wrong (transfered from my linux server to my windows desktop btw).
Further supports my belief that the data channels aren't encrypted, but only the command channel is. Also please note this also depends on your encryption key as well, a bigger one, requires more time for encoding. If you are using a 256 SSL key, and a 1024 SSH key, which is a factor of 4x. Basically here, you are trading speed for security.
"By nature men are alike. Through practice they have become far apart." Confucius (Analect 17:2)
.gif "Smile"){kind=small}
;)). You want it secure; use FTP-SSL (not ssh-ftp, because that's really slow, at least when I've tested it) to get the data encrypted, all the software I mentioned supports it. People using any operating system can connect to a ftp-server (even with ssl), all that is need is a working ftp-client. Check out http://www.pure-mac.com/ftp.html for example, it lists several client for MacOS.
