On Tuesday 19 October 2004 04.58, Garrett Rooney wrote:
> Greg Hudson wrote:
> > I hope to review this stuff more closely soon. mbk proposed creating a
> > branch for it; that way we can commit it without addressing all of the
> > build system and configuration issues immediately.
>
> That seems like a good idea.
>
> > On Mon, 2004-10-18 at 16:00, Garrett Rooney 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.
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.
So svnserve will send one of two capabilities :
ssl All access must must SSL
ssl-auth All access, except anonymous, must use SSL.
The client will then respond with the capability "ssl" for starting the SSL
handshake. If no SSL is wanted by the client, then it will not send the ssl
capability. Note that a client may very well use SSL even for anonymous
access.
With the two ssl capabilities, the setup and usage of SSL in svnserve should
be fairly easy to understand as well as administrate.
> >
> > I also don't much like the mess of new command-line options. I'd like
> > to either see these moved to the repository config file (although that
> > means the greeting will specify the "ssl" capability even if the server
> > has configured no certificates, which means the ssl handshake had better
> > do something intelligent even if there are no certificates), or see
> > svnserve grow a server configuration file before we add this many global
> > options.
> Yeah, since the remainder of the svnserve configuration stuff is
>> per-repository it seems like this should be as well.
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.
> >>> * Since the realm is sendt as part of the greeting, this will not be
> >>> encrypted.
> >>
> >>That's unfortunate. Do you see a good way to change the protocol to
> >>avoid the leakage?
> >
> > I'm not quite sure why the word "realm" is being used here. The only
> > "realm" involved in the svn protocol is the authentication realm, which
> > is not sent as part of the initial greeting.
I meant the client URL.
> >
> > If you mean the client URL, there is actually a reason to send this in
> > plain text: you may want to use different certificates (client and
> > server) for different repositories. Think of the client URL (or at
> > least the repository part of it) as an extension of the hostname and
> > port number.
Yes, with client certificates this would be usefull.
> > If we decide that it's more important to hide the client URL than it is
> > to allow repository-dependent SSL negotiation parameters, then we can do
> > it, but it's a little tricky. It would go like this: the client sees
> > the "ssl" capability in the server and knows it's going to respond with
> > an "ssl" capability, so it knows there will be an SSL handshake. So it
> > sends a placeholder in the client URL, and then sends the real client
> > URL as the first thing after the SSL security layer has been negotiated.
>
> Yeah, I can see how that could work, but I'm not sure it's worth the
> complexity.
Agreed.
> >>> * The client must at least use version 2 of the svnserve protocol.
> >>
Since the source code says that version 1 should be deprecated, I decided not
to implent SSL for that protocol.
/Sigfred
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 20 15:46:18 2004