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 <john.hart...@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"
