On Wed, 2004-10-20 at 09:34, Sigfred Håversen wrote:
> > >>> * svnserve will refuse clients that does not have SSL capability.
> > >>
> > >>I'm not sure this is the way we should go on this...
> > >
> > > Clearly not.
>
> Is the reason for not wanting SSL in all cases due to a concern for
> consumption of CPU resources? I can understand that SSL on anonymous access
> might be too much for a server.
The issue is that old clients need to be able to access new servers.
Whether to allow access (anonymous or not) without SSL is a policy
issue, and shouldn't be hardcoded into our code base.
I'm fine with having the connection always use SSL if the client and
server are both capable of it.
> We could allow non-SSL access for anonymous users, but all other users are
> required to use SSL. svnserve could send this in the greeting as a new
> capability "ssl-auth", meaning that anonymous access may or may not be
> encrypted at the discreetion of the client.
Capabilities should not be used to express policy, only what the server
and client are capable of. If further negotiation is necessary, it
needs to be done through some other aspect of the protocol--either a new
field in the greeting, or an interchange before the SSL handshake.
I don't think further negotiation is necessary, though. If the server
doesn't want to talk to a non-SSL client, it can generate an error and
close the connection. If for whatever reason the client doesn't want to
use SSL, it can just pretend it's not capable of it.
Also, the svn client doesn't really know whether it's performing an
anonymous access or not. It generally attempts to perform whatever
operation it's performing anonymously, and then responds to an
authentication challenge when the server asks. That might happen as
soon as the client connects (if authentication is required for read
access), or only after the client tries to issue a write operation.
That model presents an issue for client certificate authentication,
which needs to happen during an SSL handshake. Can we re-handshake
during an authentication challenge?
> I would prefer that svnserve has it's configuration file separate from the
> repository config file. It think it will be simpler to administrate, as well
> as code, to let svnserve have a certificate that is shared with all the
> repositories. This does not exclude the possibility of client authentication
> based upon client certificates, though. The approved client certificates
> should be per repository, and listed in the repository config file, of
> course.
One of my concerns is that some day, svnserve may support a more
flexible mapping of paths to repositories than the current
repository-root option. If the new method encompasses the server name
as well as the pathname, then we may need different server certificates
depending on which repository is being accessed.
Travis raises the interesting point that the same repository might be
accessible through two hostnames, in which case repository configuration
won't do. I don't know how common that situation will be.
I guess the way I lean right now is:
- The server certificate should be a global option, although at some
point (possibly in the future) it should be allowed to vary depending on
the hostname specified in the URL provided by the client.
- The approved client-certificates should be per-repository, as you
say.
In another message:
> If the certificate is specified in the repo config, then svnserve does
> not know if it has a valid certificate when a client connects. All it
> knows is that it can handle SSL, if needed. The more tricky part is to
> handle the SSL handshake, and that probably require more communication
> between client and svnserve before actual SSL handshake.
At least at a protocol level, SSL can be used without any certificates,
in which case it provides confidentiality but no authentication. Can
OpenSSL do this? It might actually be nice if, with no certificate
configuration whatsoever, ra_svn clients and servers used
Diffie-Hellman-protected communication, rendering casual network attacks
impossible.
(Of course, if you're running a server on an underpowered box, that
default might not work so well for you.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 22:17:45 2004