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. 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. 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. 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. 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. I still don't understand why 2) is the weakest step, nor how could I use "just client SSL certificates". 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]
