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 firstname.lastname@example.org.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Gerhard Fiedler > Sent: Tuesday, 14 August, 2007 19:39 > > 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) Not really. First, a CA (Certification Authority) is an organization, not a document; you can't "send a CA". Second, if one party could send both its evidence of identity (its own certificate) and the proof of that identity, how could you trust the certificate? (And third, SSL/TLS has about a zillion permutations, some of which don't use certificates at all - but we can ignore the less-common cases here.) > - Client verifies cert with the CA (or against its list of > trusted certs) The client can't use just the materials the server sends to verify the server's identity, because it has no reason to trust what the server sends until it's verified the server's identity. Here's how SSL/TLS is commonly used: - X.509 certificates can contain various pieces of information, but in particular they usually include an identity claim ("I'm www.foo.com"), a public key (which the recipient can use to encrypt a message to the certificate owner), and a signature. The signature is created using another certificate. - Since certificates are signed by other certificates, they create a web of endorsements. So the certificate for www.foo.com might be signed by the certificate "Bob's server-signing certificate #1", which might in turn be signed by "Bob's CA certificate", which might be "self-signed" (no one else guarantees it; it's a "root" certificate). The idea is that if you decide you can trust Certificate A and the person who owns it, then you can trust certificates signed by Certificate A, and (maybe) you can trust certificates signed by those certificates, and so on. - And since certificates also contain public keys, they create a Public Key Infrastructure (PKI). You trust Certificate A; Certificate B is signed by Certificate A; so if you want to send a secret message to the owner of Certificate B, you can use the key from Certificate B and be pretty sure the only person who can decrypt that message is the owner of B. The certificate signatures are your guarantee that the public key in Certificate B really belongs to the person (or computer, or whatever) named by Certificate B. - Organizations called CAs set themselves up to issue certificates. They say, "if you trust us to issue and sign certificates, we promise to perform some due diligence in handing them out; we'll actually try to make sure the person getting the certificate is who they say they are". (These days, there are basically three kinds of CAs: Verisign, which is the major commercial CA and believes it owns the Internet; a motly crew of small CAs in local markets; and private CAs that businesses and organizations set up for their own use.) - Parties that wish to be able to prove their identity get a certificate from a CA. (This may mean paying money to Verisign, if you want just anyone to be able to verify your certificate, or setting up your own CA if it's for your own use.) - In typical SSL/TLS on the Internet, where there's no existing relationship between server and client systems, the server will send the client its own certificate. That certificate will usually be signed by a well-known CA root certificate that the client should already trust. Alternatively, it may be signed by an intermediate CA certificate, which in turn is signed by the CA root cert, and the server can send that intermediate CA cert to the client as well. In fact, the server can send a "certificate chain" of any length to the client - but it has to lead to a certificate that's signed by a certificate the client already knows and trusts, or the client is just taking the server on faith. - The client will have a repository of trusted certificates, one of which should be the one that was used to sign the server's certificate (or the last certificate in the server's chain). > - Client uses public key to encrypt a session key and sends it > - Server uses private key to decrypt session key, and from > now on they use encryption based on the exchanged session key More or less. There's a bunch of mucking about with pre-master secrets and so on, but that's an implementation detail (and it varies among SSL versions). > So I wonder what kind of cert this is that comes with cvsnt. I haven't used sserver, but typically what SSL-enabled applications do is create a self-signed certificate at installation. The idea is that if you just want encryption without authentication, you can tell the client to accept the self-signed certificate. That exposes you to a wide range of attacks (man-in-the-middle and various other forms of server impersonation), but for a lot of applications that's acceptable - their threat model is that no one's going to go to much trouble to penetrate their security. (Whether that's a realistic threat model is another question.) 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. -- Michael Wojcik Principal Software Systems Developer, Micro Focus