Mailing-List: contact ftpserver-users-help@mina.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ftpserver-users@mina.apache.org
Received-SPF: pass (athena.apache.org: domain of john.hartnup@gmail.com
 designates 74.125.82.51 as permitted sender)
MIME-Version: 1.0
Date: Mon, 3 Oct 2011 12:21:24 +0100
Message-ID: 
 <CADsK-6N0M=jbhUhHF=C1D48htP+O5asn0YqsBvw7V6VnM=ifmA@mail.gmail.com>
Subject: AUTH TLS vs AUTH SSL
From: John Hartnup <john.hartnup@gmail.com>
To: ftpserver-users@mina.apache.org
Content-Type: multipart/alternative; boundary=0016e6d64667d95d2804ae632cc1

--0016e6d64667d95d2804ae632cc1
Content-Type: text/plain; charset=ISO-8859-1

I've found that ftpserver doesn't handle data connections for old clients
that use the deprecated "AUTH SSL" command.

The reason is that the server treats "AUTH SSL" and "AUTH TLS" exactly the
same.
However clients sending "AUTH SSL" expect data connections to be secured by
default.
"AUTH TLS" does data connections in the clear until the client sends "PROT
P".

This unintuitive nuance isn't mentioned in RFC2417 because the IETF
requested that all mention of AUTH SSL was removed. However it's covered in
previous drafts of the document, e.g.
http://tools.ietf.org/html/draft-murray-auth-ftp-ssl-06

      For backward compatibility and ease of implementation the
      following rules govern the initial expected protection setting of
      the data connection.

         [...]

         Connections accepted on the normal FTP port {FTP-PORT} with
         TLS/SSL negotiated via an 'AUTH SSL' command.
            The initial state of the data connection will be 'Private'
            (Although this does not follow [RFC-2228
<http://tools.ietf.org/html/rfc2228>], this is how such
            clients tend to work today).


I think the following in AUTH.java / secureSession() would fix it.

if("SSL".equals(type)) {
   session.getDataConnection().setSecure(true);
}

I can work out how to submit this as a patch, if I'm asked to -- but I'd be
grateful if someone who already has the workflow set up were to offer to do
it instead!

I appreciate that AUTH SSL is deprecated, so could be deemed unworthy of our
attention -- but implicit SSL is also deprecated but supported, and AUTH SSL
clients are still used in the wild.

Thanks,
John

-- 
"There is no way to peace; peace is the way"

--0016e6d64667d95d2804ae632cc1--