Re: [Proftpd-user] 534 vs 220/550 response for trying to log in when TLSRequired on

On Mon, May 1, 2017 at 9:16 PM, TJ Saunders <[email protected]> wrote:

>
> > When I require TLS, but attempt to connect with plain text, proftpd
> > responds first with a 200 response code, and then after the user sends
> > credentials, it responds with a 550 response code. I would expect a 534.
> >
> > I am using ProFTPD Version 1.3.5b-4 on Debian.
> >
> > Here is what the session looks like from FileZilla, when I tell it to
> > connect without TLS:
> >
> > Status:      Resolving address of ftp.example.com
> > Status:      Connecting to 127.0.0.1:21...
> > Status:      Connection established, waiting for welcome message...
> > Response: 220 ProFTPD 1.3.5b Server (ftp.example.com) [::ffff:127.0.0.1]
> > Command: USER example_user
> > Response: 550 SSL/TLS required on the control channel
> > Error:        Could not connect to server
> >
> > Why doesn't it respond immediately with 534 instead of 220, and is there
> > a way to force it to do so?
>
> Unlike HTTPS, FTPS does not start out with a TLS handshake.  At least,
> not the "explicit TLS" as defined in RFC 4217.  Instead, the connection
> starts out like any other FTP connection -- hence the initial 200
> response code and banner from the server, on TCP connect.  It is then up
> to the client to determine what command to send next; might be AUTH,
> might be USER, might be something else.  Thus the only time that mod_tls
> has, to inform the client that TLS is required is in response to the
> first command sent by the client.  And maybe not even then -- there are
> some commands that can/should be allowed before AUTH, such as FEAT or
> HOST.
>
> If you want to require TLS _from the very beginning_, then you have to
> use "implicit TLS", via the UseImplicitSSL TLSOption.
>


Thank you. If I wanted to force the use of implicit TLS, would that just be
a matter of adding UseImplicitSSL to my TLSOptions in the config, rather
than putting it under a virtual host as showing in the example at
http://www.proftpd.org/docs/contrib/mod_tls.html?



>
> > Failing that, why doesn't it respond with 534 Could Not Connect to Server
> > -
> > Policy Requires SSL instead of 550, which is supposed to be for errors
> > related to the file system?
>
> The 534 response code, as defined in RFC 4217, is _optional_, i.e.
> SHOULD, not MUST.  And some older FTP clients do not respond well to
> response codes that are not defined in RFC 959; they would choke on
> seeing the 534 response code.  In the interest of interoperability,
> then, mod_tls chooses to use the more accepted (and allowable by RFC)
> 550 response code.
>
> It sounds like you may be trying to address some other issue, rather
> than the particular response codes used?  Some behavior you are trying
> to implement?
>
>
Yes, indeed. I'm was hoping to lock down the server so that it won't allow
anyone to send any info that is not over an encrypted channel, even the
username, so I was surprised to see that it was allowing connections to
happen before requiring TLS.

With respect to the response codes, I was thinking that perhaps clients
were operating based on the 550 "thinking" that they could go ahead and
send more data/commands over an unencrypted channel, rather than telling
them right away (via the more specific response code) that we don't accept
anything not encrypted.

It sounds like what I really just need to do is require ImplicitTLS, and
that will do the trick.

Thanks again for your help in understanding that.

Sam

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
ProFTPD Users List   <[email protected]>
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html