[cvsnt] Setting up shared repositories
Michael.Wojcik at microfocus.com
Wed Aug 15 20:48:31 BST 2007
> From: cvsnt-bounces at cvsnt.org
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Gerhard Fiedler
> Sent: Wednesday, 15 August, 2007 14:39
> Michael Wojcik wrote:
> >> From what I read about this, sserver is pserver over SSL.
> >> AFAIK SSL works like this (simplified):
> >> - Client requests a connection, telling what ciphers it supports
> >> - Server uses best cipher it also supports and sends cert, usually
> >> containing a public key and a CA (if no CA, the cert has to be
> >> trusted on the client)
> > First, a CA (Certification Authority) is an organization, not a
> > document; you can't "send a CA".
> Of course not... :)
Well, one never knows. SSL/TLS is an arcane subject, and I've heard
stranger misconceptions from non-experts.
> What I meant with "send a CA" was "send
> the information that allows the receiver to contact a
> commonly trusted CA and verify the certificate" (like someone
> may ask me to "give [her] my email".
Actually, I can't think of any SSL/TLS implementation that does that.
There are online protocols for certificate validation - to check for
revocation and that sort of thing, and there are implementations which
store trusted certificates in some central place (eg an LDAP directory),
but I don't know of one that will take a certificate that's signed by an
unknown source and ask a proxy to verify it.
There are SSL cipher suites that don't use certificates (eg Anonymous
Diffie-Hellman), but in the normal case the server sends one or more
certificates, and most clients check that chain against a root cert
that's already in the client's store of trusted certs.
> So in the end, it seems still to boil down to that a cert has
> either to be trusted on the client, or be signed by a CA
> that's trusted on the client.
I'm not even sure the first case is supported by typical SSL/TLS
implementations. Certainly the normal case is that the server sends a
certificate chain (which might be just one certificate, the server's),
and it's signed by a root the client already trusts, or the client can't
verify the server's identity.
> And you seem to say that by installing the cvsnt client, the
> certificate that comes with it is automatically trusted (by
> the cvsnt client), right?
I don't know, as I've never looked at how sserver is implemented in
CVSNT. CVSNT could come with a trusted root that's automatically
installed by the client, and a CA that will sign server certs using that
root. That would make for very easy setup. Unfortunately, it wouldn't
provide any security under a decent threat model, because anyone could
create a server cert that the client would accept.
To offer some real security, a server that uses SSL/TLS in the normal
manner has to have a cert that's signed by a secure CA. If you're
installing such a server, you have two choices: use an existing CA (that
you trust), such as Verisign; or act as your own CA. In the latter case
(if you're not already a CA), you'll have to create a root certificate
and a key pair for it; lock the private key up somewhere safe; install
your root cert on your client systems as a trusted root; and generate a
server cert and key pair for your server.
That *can't* be automated securely. For one thing, the CA and server
private keys have to be kept private, and in practice that means they
have to be secured with passphrases, and some human will have to pick
and remember those passphrases. (If you automate that bit, an attacker
will eventually ferret them out.)
The CVSNT documentation appears to say only that sserver uses SSL to
encrypt the password on the wire. It may not do any server
authentication at all; it might use Anonymous Diffie-Hellman, or it
might use canned certificates, or it might ignore the certificate
checks. Of cours that leaves it open to trivial man-in-the-middle and
other server-impersonation attacks, so it's not really helping.
And in any event, pserver, sserver, and sspi are inherently insecure
anyway, because they store passwords in readable or reversible form. So
server authentication may well be lower in your threat model than the
very real risk of password compromise. (sspi is particularly bad
because it requires use of the user's domain password; compromise
exposes the user entirely. If pserver and sserver are used with
CVS-only credentials, then you at least make the attacker do a bit more
work to break into the user's account. Injecting a trojan into the
source code in the CVSNT repository would be a good approach.)
GSSAPI is a bit better.
> > If you want real security, with authentication, you replace that
> > self-signed certificate with a proper CA-signed one, and make sure
> > client has the appropriate root certificate available, and configure
> > the client to require a properly-signed server certificate.
> Or you use your own self-signed certificate, and make sure
> it's registered as trusted on all clients.
You could, if your client-side SSL/TLS implementation supports that, but
you'd lose the advantages of the certificate system. You wouldn't have
a PKI; you'd be publishing the server's public key to every client.
Principal Software Systems Developer, Micro Focus
More information about the cvsnt