Hi, I believe this has been discussed before on the list but I wanted to get a better understanding and confirm the current situation.
Is it still correct that when using verify=2, the peer's hostname is not checked (via a name service lookup) to match the Common Name in the presented certificate? With the main reason being that you cannot necessarily trust the name service?
I am asking because we have a closed network in which we do trust our dns servers, and Common Name checking would be advantageous to us given the following scenario:
We have is that a single (central) host that connects to multiple 'client' hosts via stunnel. The central host presents a certificate signed by our own CA. Each client has a copy of our CA's certificate and has verify=2. So when the central server connects, the client checks that the certificate presented has really been signed by our own CA. So using this mechanism, only servers (i.e. the central server) with a signed certificate are allowed to connect.
All good so far, however the problem is if the signed certificate is copied (stolen) to another server. This 'other' server can connect to all the clients also. With Common Name checking, the clients could as well as checking the signature, check the presenting host has the same hostname as in the certificate.
Is there anyway we can use stunnel to help us guard against this 'stolen cert' situation or if not what else could we do?
Thanks, Mark
Mark Bolton [email protected] wrote:
Is there anyway we can use stunnel to help us guard against this 'stolen cert' situation or if not what else could we do?
Sure. CRLs are designed exactly for this purpose. http://en.wikipedia.org/wiki/Certificate_revocation_list
Best regards, Mike
Hi Mike, Thanks for your reply, however a CRL will only help if we find out about it.
We want to prevent it from happening of course, but we want to remove the incentive as well. With a CRL, there is a window of opportunity between the time the cert is stolen and when the theft is discovered. How can we close that window?
Regards, Mark
-- Mark Bolton
On 14 Jul 2009, at 14:13, Michal Trojnara <Michal.Trojnara@mobi- com.net> wrote:
Mark Bolton [email protected] wrote:
Is there anyway we can use stunnel to help us guard against this 'stolen cert' situation or if not what else could we do?
Sure. CRLs are designed exactly for this purpose. http://en.wikipedia.org/wiki/Certificate_revocation_list
Best regards, Mike _______________________________________________ stunnel-users mailing list [email protected] http://stunnel.mirt.net/mailman/listinfo/stunnel-users
Mark Bolton wrote:
Thanks for your reply, however a CRL will only help if we find out about it.
We want to prevent it from happening of course, but we want to remove the incentive as well. With a CRL, there is a window of opportunity between the time the cert is stolen and when the theft is discovered. How can we close that window?
You mean the private key and not the certificate, right? I'm afraid you can't. The security of public-key cryptography is based on the security of private keys.
Web browsers implement some DNS checks. Since you can spoof DNS, it's not something you can rely on.
In some cases it's also possible to implement some sort of IP-based access control. This is a pain to maintain and not really a bulletproof solution.
Best regards, Mike
-
Mark Bolton -
Michal Trojnara