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

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

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

Cheers,
TJ


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