Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> 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 the > > 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. -- Michael Wojcik Principal Software Systems Developer, Micro Focus