On Sat, Oct 6, 2012 at 5:41 PM, Charles Mills <charl...@mcn.org> wrote:
> 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.
>
If you are using RSA, then the public key is {e,n}. When a client
connects to a server, the client ensures the {e,n} in the server's
certificate is expected. You can usually find it at certificate[0]. In
essence, you have white listed the {e,n} pair for the host in
question.
If using ECC, you have two items to verify: the [public] point and
domain parameters. For prime fields, the public key is the point, Q
(or (qx, qy)), and the domain parameters are {p, a, b, G, n, h} (G is
a base point and sometimes denoted as (gx,gy) pair). Again, its a
whitelist of expected values for the host.
If you are using ephemeral key exchanges, then certificate[0] will be
a temporary, throw away key. Ephemeral is good because it provides
forward secrecy. In this case, the server's certificate/public key is
used for authentication, and the public key of interest can be found
at certificate[1]. certificate[1] must sign certificate[0] (some hand
waiving since certificates can't sign one another).
Jeff
> -----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
