Enforcing SSL

[dustin hunter <co...@gmail.com>]

I pulled your trunk code and got an embedded FTPS server up and running
(exactly what I needed). I noticed however, that while the authentication
seems to work, it also allows non-secure clients to login.

Do you know how I can disable this?

Thanks

Re: Enforcing SSL

[Dave Roberts <da...@saaconsultants.com>]

Niklas Gustavsson wrote:
> I'm probably particular thick today  :-) Just to make sure I understand 
> what you mean. What you would like is to have an option that enforces a 
> client to send the AUTH command before USER/PASS, right? 

First off, it's not so much about what I'd like, rather an idea born
out of your response to the original poster. :)

Let's backtrack for a moment...

Dustin asked if it was possible to stop non-secure clients from
logging in.

You correctly stated that they could use implicit SSL but also added
that that only forces SSL for the control socket, not the data socket.

My follow up was meant to point out that if you add a configuration
option to ensure AUTH is sent before LIST/etc, a user could still
login without any protection, and not be warned of needing SSL until
they do a LIST.  However, by that time, the USER and PASS commands
have been transfered in the clear.

So my idea was to have that config option to reject the USER command
if SSL isn't already enabled.

However, I got suckered in there for a minute.  What I should have
asked is: why does the server not secure the data socket when using
implicit SSL?  This, I believe, is what the Murray draft required.
If I'm wrong on that point, then my initial suggestion stands.

Re: Enforcing SSL

[Clinton Foster <cf...@us.axway.com>]

I'm arriving a little late to this discussion, but I do think it would be
very useful to provide a means for turning away clients at the point of the
USER command if the connection is not secure. Requiring explicit SSL is one
solution, but it is somewhat restrictive since explicit initiation via AUTH
TLS is so common these days.

I had a less restrictive requirement to do this only if client-authenticated
SSL was configured (since accepting clear connections would defeat the
purpose of client authentication). I implemented it in USER.execute() as
follows:

    if (connection.getControlSocket() != null &&
!(connection.getControlSocket() instanceof SSLSocket)) {
        Ssl ssl = serverContext.getSocketFactory().getSSL();
        if (ssl != null && ssl instanceof DefaultSsl) {
            if (((DefaultSsl)ssl).isClientAuthRequired()) {
                log.warn("Client attempted to login without an authenticated
secure connection: " + connection.getControlSocket());
                out.send(501, "USER.client.auth.required", null);
                return;
            }
        }
    }

This also required an additional entry in the message file:

501.USER.client.auth.required=Secure connection with client authentication
certificate is required to login.

And it required the addition of a getSSL() method to DefaultSSL().

That¹s probably not the cleanest implementation, but you get the idea. In my
particular case I did not need to require SSL unless client authentication
was configured. But it would be even more flexible to have a configuration
option to require SSL whether or not client authentication is configured.

Clint

On 5/1/07 12:06 PM, "Niklas Gustavsson" <ni...@protocol7.com> wrote:

> I'm probably particular thick today  :-) Just to make sure I understand
> what you mean. What you would like is to have an option that enforces a
> client to send the AUTH command before USER/PASS, right? How would this
> differ from setting up the listener to always use SSL on the control
> socket (with implicit SSL)? If using imlicit SSL, the client would be
> forced to, or it could not even get through the SSL handshake and
> establish a socket connection.
> 
> /niklas

Re: Enforcing SSL

[Niklas Gustavsson <ni...@protocol7.com>]

Dave Roberts wrote:
> Niklas Gustavsson wrote:
>> Dave Roberts wrote:
>>> Niklas Gustavsson wrote:
>>>> What would you all think of this, would it be useful? 
>>> Sounds useful to me. Sometimes it's the operator of the server that
>>> wants to protect the data, and the client users don't care.
>>> Enforcing this seems a good solution.  Whilst there, it'd be useful
>>> to enforce that SSL is running before the client sends the USER
>>> command, to stop passwords being given away.
>> Since the USER command is sent on the control socket, you can already 
>> enforce this using implicit SSL. Or, am I misunderstanding something=
> 
> That's true, I was thinking about ensuring both the USER/PASS and
> the data connections were secured.
> 
> If a change is made to ensure that SSL is in place for the data
> channels only, then the user could end up doing a login in the
> clear, resulting in the credentials being revealed.

I'm probably particular thick today  :-) Just to make sure I understand 
what you mean. What you would like is to have an option that enforces a 
client to send the AUTH command before USER/PASS, right? How would this 
differ from setting up the listener to always use SSL on the control 
socket (with implicit SSL)? If using imlicit SSL, the client would be 
forced to, or it could not even get through the SSL handshake and 
establish a socket connection.

/niklas

Re: Enforcing SSL

[Dave Roberts <da...@saaconsultants.com>]

Niklas Gustavsson wrote:
> Dave Roberts wrote:
>> Niklas Gustavsson wrote:
>>> What would you all think of this, would it be useful? 
>> Sounds useful to me. Sometimes it's the operator of the server that
>> wants to protect the data, and the client users don't care.
>> Enforcing this seems a good solution.  Whilst there, it'd be useful
>> to enforce that SSL is running before the client sends the USER
>> command, to stop passwords being given away.
> 
> Since the USER command is sent on the control socket, you can already 
> enforce this using implicit SSL. Or, am I misunderstanding something=

That's true, I was thinking about ensuring both the USER/PASS and
the data connections were secured.

If a change is made to ensure that SSL is in place for the data
channels only, then the user could end up doing a login in the
clear, resulting in the credentials being revealed.

Re: Enforcing SSL

[Niklas Gustavsson <ni...@protocol7.com>]

Dave Roberts wrote:
> Niklas Gustavsson wrote:
>> What would you all think of this, would it be useful? 
> 
> Sounds useful to me. Sometimes it's the operator of the server that
> wants to protect the data, and the client users don't care.
> Enforcing this seems a good solution.  Whilst there, it'd be useful
> to enforce that SSL is running before the client sends the USER
> command, to stop passwords being given away.

Since the USER command is sent on the control socket, you can already 
enforce this using implicit SSL. Or, am I misunderstanding something=


/niklas

Re: Enforcing SSL

[Dave Roberts <da...@saaconsultants.com>]

Niklas Gustavsson wrote:
> What would you all think of this, would it be useful? 

Sounds useful to me. Sometimes it's the operator of the server that
wants to protect the data, and the client users don't care.
Enforcing this seems a good solution.  Whilst there, it'd be useful
to enforce that SSL is running before the client sends the USER
command, to stop passwords being given away.

> What would be the
> correct error code to send in the case where a client for example
> sends a LIST and haven't done a PROT first?

RFC 959 states that we could use 450 (Requested file action not
taken) but that is a transient error, which the client could choose
to try again without making any changes.

So we want something in the 5xx range, of which the following are
permitted: 500, 501, 502, 530.  I would go for 501 (Syntax error in
parameters or arguments) and change the message to (Syntax error,
SSL must be used) or something similar.

501 can also be used as a return code for the USER command.

Re: Enforcing SSL

[Niklas Gustavsson <ni...@protocol7.com>]

Hi Dustin,

dustin hunter wrote:
> I pulled your trunk code and got an embedded FTPS server up and running
> (exactly what I needed). I noticed however, that while the authentication
> seems to work, it also allows non-secure clients to login.
> 
> Do you know how I can disable this?

What you could do, is to only use implicit SSL 
(http://incubator.apache.org/ftpserver/tlsssl-support.html). However, 
that will only force SSL for the control socket, not for the data 
socket. What we could do in FtpServer is to offer a configuration that 
would not allow any commands that use the data socket until the client 
sends a PROT P command. Would that be appropriate for your needs?

What would you all think of this, would it be useful? What would be the 
correct error code to send in the case where a client for example sends 
a LIST and haven't done a PROT first?

/niklas