Thanks. I'm a relative newbie to this whole topic. Can you point me to a resource that describes "pin" in the sense you use it below? The word is too common for the Google to be much help.
Charles -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Saturday, October 06, 2012 4:40 PM To: openssl-users@openssl.org Subject: Re: Best practice for client cert name checking On Sat, Oct 6, 2012 at 9:52 AM, Charles Mills <charl...@mcn.org> wrote: > I have recently written a product that incorporates SSL/TLS server > code that processes client certificates. I designed what I thought > made sense at the time but now I am wondering if what I did was best. > > In the product's configuration file the sysadmin may optionally > include a whitelist of client names. If the sysadmin does so, then the > server requests a client certificate. At least one of the names > (subject O= and Alternative names, including wildcards) in the > certificate must match one of the names in the whitelist or I reject the > session. > > Something I saw recently got me to wondering whether I should have > made some sort of provision for checking IP addresses: perhaps > verifying that the client IP address appeared in the Alternative names > in the client certificate as well as in the whitelist? Or perhaps that > the IP address matched an alternative name and the subject name appeared in > the whitelist? You have a pre-existing relationship. There is no need to confer trust to a third party (the CAs). There's no need to use naming and location services (DNS) since its a weak assurance at best. To improve the security posture, pin the certificate or public keys. Because the relationship already exists, you already know what the public keys are. No need to trust a third party, and no need to depend upon DNS, no need to tolerate other infrastructure failures. Problems with PKI in general: www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf History of PKI and CA failures: http://wiki.cacert.org/Risk/History Reasons to Pin in mobile: http://lists.owasp.org/pipermail/owasp-mobile-security-project/2012-August/000345.html Google also Pins their public keys on the desktop. Its the reason Chrome did not suffer Diginotar's failure. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
