Hi

The good TJ Saunders investigated the FTPS errors introduced with 7.14.1 and
he identified the problem with great details. See below for the mail TJ
posted to the proftpd-user mailing list.

I intend to revert that SSL negotiation change back to 7.14.0 status.

-- 
          -=- Daniel Stenberg -=- http://daniel.haxx.se -=-
---------- Forwarded message ----------
Date: Mon, 26 Sep 2005 17:28:24 -0700 (PDT)
From: TJ Saunders
Subject: Re: [Proftpd-user] Re: problems with ftps (using libcurl)
> The original bug report that caused this "fix" is here:
>
>  	http://curl.haxx.se/mail/archive-2005-08/index.html#16
>  	http://curl.haxx.se/mail/archive-2005-08/0016.html
>
> There's a long thread there for the discussions around this problem.
I see.
In the case of proftpd+mod_tls, your libcurl change _does_ cause problems,
precisely because mod_tls _does_ wait until after sending the response to
a data transfer command (e.g. STOR) before starting the SSL/TLS handshake,
as per the FTPS Draft (draft-murray-auth-ftp-ssl-16.txt):
    13.6. A standard data transfer with protection
            Client                                 Server
   control          data                   data               control
====================================================================
                    socket()
                    bind()
   PORT w,x,y,z,a,b -------------------------------------------->
       <-------------------------------------------------------- 200
   STOR file --------------------------------------------------->
                                           socket()
                                           bind()
       <-------------------------------------------------------- 150
                    accept()  <----------  connect()
                    TLSneg()  <----------> TLSneg()
                    TLSwrite() ----------> TLSread()
                    TLSshutdown() -------> TLSshutdown()
                    close()    ----------> close()
       <-------------------------------------------------------- 226
Notice that the TLSneg() handshake occurs after the 150 response code to
the STOR has been sent to the client.
In one of your posts, you comment:
   "While that occurred to me too, I don't consider this fix a bad one. It
    should work on all RFC-compliant servers as well and it actually makes
    more sense to do the SSL-related connection stuff just after the TCP
    connection has been confirmed and not at an arbitrary later point like
    this."
Even though the TCP connection endpoints are confirmed, it doesn't mean
that a new TCP connection is opened for the data transfer at that time.
Consider the case where, after a PASV or PORT command, the client issues a
RETR for a path that does not exist.  ProFTPD, in this case, will send an
error back via the command channel, and not bother opening a data
connection which will never be used.
TJ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    A man said to the Universe: "Sir, I exist!"
    "However," replied the Universe, "the fact has not created in me a sense of
    obligation."
    	-Stephen Crane
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~