hi Michel, On Tue, Jun 03, 2003 at 08:20:04PM +0200, Michel Gouget wrote: > Many thanks Vadim for assuring me that keys/certificates can't work if they > are not matched, and your observations on my architecture. > > My vision is that (k0) (2048 bits) will *never* be compromised during > application's life (~20 years), as it is kept in a bank safe in a sealed > envelope, and is used only once to sign (ca1). (k1) *could* be compromised, > as it is needed to sign server certificates, but this is done at a single > place.
so k0 might be used once again to sign ca1 replacement in (unlikely) case of k1 compromise > On the client, (ca1), then (ca2) are verified at startup. If I understand > correctly the certificate technology, a certificate is a rope which ties > together a DN and a private key, no more, no less. It "ties" DN, public key, validity dates and extensions. The tie mentioned is the signature. > Verifying certificate > (c1) means for me: "verify that God (ca0) has really certified that (DN1) > goes with (k1)" in order to be *sure* that if someone uses (k1), *then* he > is named (DN1). At the second level, it means that if I have verified (DN1) > and that (k1) has been used to sign (c2), *then* I can be sure that if > someone uses (k2), he is named (DN2), *unless* (k1) has been compromised.. > So in fact my only trusted certificate is (ca0). Maybe I have not really > understood what is a trusted certificate. Yes, exactly. One could also elaborate "using private key" means making signatures (issuing certificates) or participating in a protocol (SSL). The trusted certificate is one verified some other way, say using fingerprint from paper agreement. Or maybe one signed using a private key generated and controlled by you alone. > You are right that if (k2) is compromised, all (ca3) certificates must be > recreated with a (k2') key, but I have not found a better solution > > Concerning (k3), they are stored *encrypted* on the server, and are > encrypted with 3DES whose strength matches the 2048 bits RSA key. The > passphrase (p3) entered by the user is sent over the network only *after* > having checked that we are connected to the correct server (i.e. client has > checked server certificate). (p3) is only used in-memory by the server to > check that it decrypts correctly (k3), then erased. (k3) is sent back still > encrypted by (p3) over the wire. so this security model is equivalent or weaker than using passwords over SSL without client certificates at all: - a client who knows the password will get access anyway - a client who got SSL client certificate and private key at least once some time ago could use it to get access disregarding the password changed already > I did that because users can use different clients, and a client can be used > by different users, so I could not store state information on the client. > (ca3, k3) are in fact attached to the user's DN. In that scheme, state > information is carried by the user in the form of (p3), as, unfortunately > :-), I can't ask users to remember the 2048 bits of their private key. In this case one could just tell the user the effective level of security and let them choose the right client software/hardware > I still don't understand why 2) is the weakest step, nor how could I use > "just client SSL certificates". Let's assume a user write the password on a yellow stick and put it on the monitor for a hour. Someone complains and password got replaced. However before password was changed someone got client SSL certificate and private key using that (old) password and store them. Now that client can access the service without any password at all, isnt it? Another possible point of failure is server-side passwords store. This means one can fetch the passwords store after a server compromise and fetch lots of SSL client certificates and private keys. Distributing new passwords for all clients might be a very hard job. To decrypt the SSL client private key one should store passwords in clear. This means passwords are available immediately after a server compromise. Please note there's a time-frame to crack passwords in case of keeping password hashes, not cleartext. The service admin might stop the service before cracking process will list some portion of passwords in case he notice the compromise. With client SSL certificates there's no server-side password store. With passwords over SSL and no client certificates one could disenroll by replacing a single password and store password hashes instead of cleartext. Both options looks better to me. yours, Vadim > > Once again, thanks, > > Michel > > ----- Original Message ----- > From: "Vadim Fedukovich" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, June 03, 2003 6:53 PM > Subject: Re: Philosophical question: What means verifying a connexion ? > > > > On Tue, Jun 03, 2003 at 12:22:35PM +0200, Michel Gouget wrote: > > > Dear all, > > > > > > I am now fluently using Openssl in a (rather complex) closed group > > > application - Great !!! :-) - > > > A server, implemented as a fastcgi ( http://www.fastcgi.com/ ) > application > > > behind an Apache web server using mod-ssl, answers http requests made by > > > (software) clients. All connections are done through the (public) > Internet. > > > CRLs are not managed actually. > > > > > > There is a root private key (k0), and a self-signed certificate (ca0). > (ca0) > > > is hard-coded in C in my client and server programs. > > > An intermediate certificate (ca1, with CA privilege, key k1, signed by > ca0) > > > is used to sign the server certificate (ca2, with CA privilege, key k2 > and > > > passphrase p2) (manual process). > > > All clients have (ca1) and (ca2) (trusted) available locally. > > > > Having ca2 trusted means complicated server certificate and private key > > replacement procedure. It is generally believed one can limit risk of > > k1 (or maybe k0) compromise and use ca1 (or ca0) for server certificate > > verification. > > > > > Client certificates (ca3, with key k3 and passphrase p3) are generated > by > > > the server and signed by (k2). (ca3) and (k3) are stored on the server, > (p3) > > > is destroyed. > > > > Limited-risk key (k1) is generally used to sign other keys. > > Please remember k2 is online on a host running some application. > > > > > The apache server uses (ca2, k2), does *no* verifications on incoming > > > requests, but tries to get the client certificate if there is one; i.e.. > in > > > httpd.conf: > > > <Directory "/var/www/fcgi-bin"> > > > SSLVerifyClient optional_no_ca > > > SSLVerifyDepth 10 > > > SSLOptions +StdEnvVars +ExportCertData > > > </Directory> > > > > > > When a user login on a client, he enters his DN and passphrase (p3); the > > > client initiates a crypted tls connection (c1, *without* certificate), > > > containing passphrase (p3) to Apache, which sends it to my server. > > > The server checks that p3 matches k3, and send back (ca3, k3). > > > The client then reinitialize the connection and now uses (ca3, k3) for > the > > > remaining (c2) connections to the server. > > > > This scheme looks equivalent to password authentication over SSL/TLS. > > At least two concerns are there: > > - server should keep password in clear, as-is. Recovery from server > > compromise means re-generating and distributing all user passwords > > and it's a lots of work to do. > > - passwords are sent over the wire, well inside the SSL/TLS connection. > > This introduce the risk of single point-of-failure. > > > > With just client SSL certificates, passwords are only used locally to > > protect private keys. Private keys are not sent over network, > > only signatures made with that keys (the most popular RSA mode of > SSL/TLS). > > It is believed there's no way to learn private key from the signature. > > Ok, at least for X.509 world without any Brands-style limited-show > credentials. > > > > At the server side, no password is required to verify the right private > key > > (corresponding to the client SSL certificate) was used. No private key > > is required to verify the CA signature. > > > > Are you sure it's still Ok to keep passwords to access SSL client private > > keys on the server? > > > > > Through fastcgi, the server is > > > able to get the peer certificate. This certificate (ca3) is then used by > an > > > ACLs subsystem on the server to allow/deny various requests, depending > on > > > parts of the DN. > > > > > > The client verifies everything "by hand", i.e.. > > > SSL_CTX_set_verify(sslctx, SSL_VERIFY_PEER > > > | SSL_VERIFY_FAIL_IF_NO_PEER_CERT > > > | SSL_VERIFY_CLIENT_ONCE, null_verify_callback); > > > All the certificates and keys are loaded using PEM_xxx(), and their > validity > > > dates are checked. > > > > > > So I have many places where I must "verify the connection": > > > 1) Client, when initiating (c1): Is it the "right" server? > > > 2) Server when receiving (c1): Do I have to send back (ca3, k3) ? > > > 3) Client, when initiating (c2): Is it the right server ? > > > 4) Server, when receiving a (c2) request: Who is *really* sending this > > > request ? > > > > ..well, it's the same client that got (k3,c3) once some time ago > > as a response to the right password > > > > > At initialization, the server and clients check that their local copies > of > > > (ca1) are signed by their (hard-coded) (ca0), then verifies that (ca2) > is > > > signed by (ca1). > > > > this step make sense if/when only ca0 is trusted > > > > > For 1) and 3), when the tls handshake is done, the client checks that > the > > > peer certificate is the same as the local (ca2), using X509_cmp() . This > > > verifies that the received (ca2) is indeed the true one. But how can I > be > > > sure that the server is *actually* using (k2) ? > > > > SSL protocol would fail in case server would try using another private key > > not corresponding to server certificate > > > > > 2) poses no problem, as the server has just to check that (p3) decrypts > > > (k3). > > > > I believe it's the weakest step. > > Just client SSL certificates would be better. > > > > > 4) The server checks that the received (ca3) is the same as the local > one. > > > But same question as 2): How can I be sure that the peer *really* uses > (k2) > > > and not a dummy private key? > > > > it's a part of SSL protocol (client certificate) and it was done the right > way. > > In short, signature (made with client private key) would not verify and > > SSL handshake would fail. > > > > > Is there some kind of > > > SSL_check_private_key(ca2, BIO) for the server side ? > > > > > > Sorry for this lengthy post, but I have not found yet an answer to this > > > basic question. In addition, I'd greatly appreciate getting feedback and > > > comments on this architecture from you *real* SSL gurus, as I have no > past > > > experience in this field. Have I done something idiotic, overly complex > or > > > did I missed an important point? > > > > > > Michel Gouget > > > > > > > > > > > > > > > ______________________________________________________________________ > > > OpenSSL Project http://www.openssl.org > > > User Support Mailing List [EMAIL PROTECTED] > > > Automated List Manager [EMAIL PROTECTED] > > > > good luck with your project, > > Vadim Fedukovich > > > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > > User Support Mailing List [EMAIL PROTECTED] > > Automated List Manager [EMAIL PROTECTED] > > > > > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager [EMAIL PROTECTED] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
