Hi,

On Thu, 2009-02-26 at 14:40 +0900, Yutaka Sato wrote:
> The problem is in the implicit-negotiation of SSL usage in FTPS of which
> specification is not well specified.  In your case, DeleGate is waiting
> SSL negotiation from the client on the data-connection but lftp does not
> do SSL (at least by default) for a FTPS server.

Aha!  Thank you for the information.  I read some of RFC 2228 and I see
the problem is that lftp never issues a PROT command (most likely
because delegate does not list PROT in its supported commands when in
ftps mode).  So, I have delegate configured to require an encrypted data
channel and lftp assumes it is PROT level C.  I suppose this means my
use of delegate is actually wrong according to the RFC.  The RFC expects
something like:

delegated -P990 SERVER=ftps MOUNT="/* ftp://upstream-ftp-server/*" REMITTABLE=+,ftp STLS=fcl:990,-fcl

After some experimentation, I found I can get lftp to work as I was
expecting using lftp's ftps:initial-prot setting.  With this delegate:

delegated -P990 SERVER=ftps MOUNT="/* ftp://upstream-ftp-server/*" REMITTABLE=+,ftp STLS=fcl

And lftp like this:

lftp -d 'ftps://anonymous@delegate-ftp-server/'

Then when in lftp, issuing the following commands (so for long-term use
putting this in the lftp.conf file would make sense):

set ftps:initial-prot P
reconnect

After that I can ls and it uses SSL.

I did notice one problem.  If delegate is configured to require
encryption on the data channel, it will still accept "PROT C" from the
client.  So the client says "PROT C" and delegate says "200" but then
the client will hang when it tries to download the file.  I think the
RFC is clear delegate should reject the PROT with "534" (protection
level refused).

Thanks for the help,
-Jacob

-- 

Jacob Lundberg
Director, IT Services
pdeiqbdyi-qghxypivy3y6.ml@delegate.org
503.290.0100 (voice)
503.973.5252 (fax)
541.990.2248 (cell)