On Thu, 15 Sep 2005, Yang Tse wrote:

(CC'ing the libcurl list, we're talking libcurl devel details here...)

> Hi,
>
> Version 1.4.1 has introduced a documented change to the ftp.c file
> which affects ftp-ssl and ftps passive modes.

Version 7.14.1 did, yes.

> Its purpose was to make the SSL/TLS negotiatiation immediately after the TCP
> data connection is done, instead of doing the SSL/TLS for the data
> connection once some commands have been sent over the control conecction.
>
> It seems that this change was introduced because at least one ftp server
> required this "early SSL" to be able to establish a proper connection.

A very accurate description, indeed.

Thanks for bringing up this subject!

> The fact is that this change also at least breaks the connection of curl
> with other ftp server which requires the "late SSL" which has existed up to
> version 1.14.0

Yes, it seems to be what hits some people.

So far, we have not got/done any detailed investigations what really happens
and why the servers don't like this. I can't really understand why this
earlier SSL negotiation is not OK (both technical and RFC wise). I also
installed pureftpd and proftpd and tested myself just to get this problem and
investigate, but they both worked fine for me (using both 7.14.0 and 7.14.1).

Can anyone repeat this problem with a (preferably linux based) ftpd or
possibly allow me have a test account/run against an installtion? Does anyone
know or suspect why this happens?

Situations like this make me wish we had closer contact with some of those
servers' developers... :-)

> It would be nice if we could give curl an option called "--early-ssll", or
> something similar, to force the "early SSL" and by default use the one which
> existed up to version 1.4.0. Or maybe the other way round.
>
> Can this be achieved easily ?

Adding such an option would be rather easy, especially since we have a
stand-alone patch that brings back the old behaviour.

But (there is always a but): it would be seriously painful to users. How would
a user know what option to use? When would a user try the other option? People
and applications that use libcurl for FTPS transfers would have no real way of
knowing when a failure would be due to this option being (un)used.

Apart from the bad feeling it would leave us with if we just add a weird work-
around for a problem we don't understand why it is happening.

I view an addition of such an option as the last thing to do when all other
attempts to fix this have failed.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html