Posted: Tue Apr 25, 2006 1:19 pm
Oops, of course, I was thinking of ssl-fxp (you send CPSV instead of PASV).Rahly wrote:Although, PXR has it wrong. SSL is negotiated BEFORE commands are sent, or its not SSL.
I don't really know how it works, but in all ftp-client software I've tested you are able to choose if you want to encrypt the file data as well as the command channel. In the server you should be able to enforce not only encryption of the command channel, but also the data ones. Never seen anything about encryption of files only when in ASCII-mode though, it always encrypt no matter what mode (perhaps this can differ). Here's a sample from the config of ioFTPD btw:Rahly wrote: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.
Code: Select all
### Encryption ###
Require_Encrypted_Auth = *
Require_Encrypted_Data = !*
Certificate_Name = certificatename
Explicit_Encryption = True
Encryption_Protocol = SSL3
Min_Cipher_Strength = 128
Max_Cipher_Strength = 256Okey, I kinda guessed about the binding.Rahly wrote: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.
But anyway, it should be possible to restrict other ip-addresses than the client's ip to download the current file. Yes, I know that portscanning occurs automatically and so on, but I still can't believe that anyone of those actually will connect to the correct port on the server in that really short period it's open for clients. This shouldn't be a problem anyway if the filedata is encrypted.
When I transfered with FTP I used SSL for both commands and file data, probably with a SSL key of 256bit. In WinSCP I used the standard settings, I've got no idea how big of a key that was used in that case.Rahly wrote: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.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).