Thank you so much for this really useful reply. I made a typo in my reply; when I said "I also put these in .ftprc:" I had actually meant that I had put these in my .lftprc file - sorry!
Also thank you for the information about the certificates. It seems like I should ask the people at the server end to set up the certificates and we should use that to ensure no spoofing. One last thing: I wanted to check that it is definitely doing the encryption. You say to look for this: > ---> PROT P > <--- 200 PROT now Private. Well I am testing this on 2 machines, and the main machine on which I will eventually be running this, is quite old and the version of lftp is 3.0.6, and it doesn't produce any output for "PROT", except once at the beginning (just says PROT by itself). Running exactly the same setup on a (Fedora) machine, version of lftp, 3.5.10, then it does show the line PROT P And no lines with PROT C So I am fairly sure that, yes, it is all encrypted. I have set the debug to 12. Is this the highest value? Thanks again, Ross > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Daniel Fazekas > Sent: 24 August 2009 15:33 > To: [email protected] > Subject: Re: Need to use ftps (NOT sftp) on RHAS4 > > On Aug 24, 2009, at 15:22, MacIntyre, Ross A wrote: > > > HOST='ftps://remote_machine.com:990' > > Normally for FTP you don't even need to specify ftps in the URL. > The client and server just start off with an unencrypted conversation > like > "Server: Hello, I'm an FTP server which supports SSL/TLS. > Client: Great, I support that too, let's turn TLS on then." > > This way the same ftp server on the same port could possibly allow > both encrypted and unencrypted communication. > > On the other hand, if you put ftps:// in the URL, which causes lftp to > default to port 990, the whole conversation starts with establishing > the ssl (tls) connection before any kind of FTP protocol handshaking. > > So if the above URL works for you, the command channel - where your > password is also getting sent - is definitely encrypted and the "set > ftp:ssl-force true" is actually superfluous but doesn't hurt. > > > I also put these in .ftprc: > > I'm not sure about .ftprc. > That's probably ignored. > > The man page only says: > On startup, lftp executes /etc/lftp.conf and then ~/.lftprc and > ~/.lftp/rc. You can place aliases and `set' commands there. > > I use ~/.lftp/rc myself. > > You can start lftp to get the lftp prompt and type an empty "set" to > see which options were set. > > > My username and password are in ~/.netrc > > You could also make it a bookmark in ~/.lftp/bookmarks: > myserver ftps://username:passw...@remote_machine.com/ > > Then you can connect to it simply by typing > > lftp myserver > > (Or "open myserver" at the lftp :~> prompt.) > > This way you can control the username/password/host name in the same > file. Whichever you like better. > > > Since I don't get this error message can I assume that everything > > that is sent is encrypted? > > Because you put your options in ~/.ftprc rather than ~/.lftprc or > (~/.lftp/rc) and as a result were likely ignored, I believe everything > BUT the data transfers were encrypted. > > a) control channel was encrypted, since you used an ftps:// URL > b) directory listings were encrypted, since ftp:ssl-protect-list > defaults to true anyway > c) actual file transfer data was sent in clear, since ftp:ssl-protect- > data defaults to false > > In lftp's debug output it would look like this before each file > transfer: > > ---> PROT C > <--- 200 PROT now Clear. > > (turns encryption off) > > Then before the next direcory listing, it would turn it back on: > > ---> PROT P > <--- 200 PROT now Private. > > > As you can guess I am fairly new to the ssl and certificates, but I > > need to be sure that the data I download is secure, > > The encryption part covers the data security in that third parties > can't eavesdrop on it while in transit. > But consider that somebody hijacked the DNS entry for the target > machine and simply set up his own SSL-capable FTP server on the same > port. > Then you'd just go ahead and send the login information to the rogue > server and download data from it - still encrypted, just from the > wrong party. > > That's where the certificate validation part comes in. > You proceed with the communication only if the server presents a > certificate signed by a certificate authority you trust. > If you care about this part of the security, you'll also have to set > > set ssl:verify-certificate yes > > And point lftp to the CA bundle which contains at least the > certificate authority which signed your server's certificate, > eg.: > set ssl:ca-file "/usr/etc/ca-bundle.crt" > > Now you wrote it said > > WARNING: Certificate verification: self signed certificate > > So your server doesn't actually seem to have a proper certificate > signed by an outside certificate authority. > You should still be able to get that CA cert and point ssl:ca-file at > it, but I don't have much experience with self-signed certificates > myself. > > > Can I put the setting of these 6 ftp:ssl-* variables in the script > > itself? > > Yes, if you like. -- Heriot-Watt University is a Scottish charity registered under charity number SC000278.
