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: 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