AUTH TLS vs AUTH SSL

[John Hartnup <jo...@gmail.com>]

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"

Re: AUTH TLS vs AUTH SSL

[John Hartnup <jo...@gmail.com>]

Further to this, judging by the IETF draft, "AUTH TLS-C" should be accepted
as a synonym for "AUTH TLS". By inference, judging by some emails on this
list a few months ago, "AUTH TLS-P" should be accepted as a synonym for
"AUTH SSL".

On 3 October 2011 12:21, John Hartnup <jo...@gmail.com> wrote:

> 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"
>



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