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