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. Jeff ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
