Re: Best practice for client cert name checking
On Thu, Oct 11, 2012 at 6:47 PM, Charles Mills charl...@mcn.org wrote: Thanks. My boss is not technical. I am the CTO of this product. Our customers are your basic commercial customers. Yes, I picture that they would be their own CA. Why pay Verisign if you don't have a bunch of people sitting at their PCs trying to buy widgets from your Web site, and wondering if they can trust it. Yes, I support a local CRL file. I would explain this to you from a risk acceptance point of view, but I don't want to hijack your thread again [SNIP] Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
Thanks. My boss is not technical. I am the CTO of this product. Our customers are your basic commercial customers. Yes, I picture that they would be their own CA. Why pay Verisign if you don't have a bunch of people sitting at their PCs trying to buy widgets from your Web site, and wondering if they can trust it. Yes, I support a local CRL file. I think our customers' situation is likely a LOT like yours: relatively few machines, possibly distant and possibly on the public Internet. It's basically an unattended box to unattended box product, so the problem is identifying machines, not people. Yes, IP addresses change. Obviously if someone is changing IP addresses a lot they would have to change the whitelist a lot. I've got other fish to fry at the moment, but I kind of like the idea of offering if and only if the 'names' on the whitelist are IP addresses then one (possibly wildcarded in the low-order node) must compare equal to the incoming IP address, and the incoming IP address must also compare equal to a (possibly wildcarded) name in the certificate. This would *help* (everything is a help, right, nothing is absolute) with the problem of a client certificate that got away into the wild, right? Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dave Thompson Sent: Wednesday, October 10, 2012 12:48 PM To: openssl-users@openssl.org Subject: RE: Best practice for client cert name checking From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Monday, 08 October, 2012 07:47 Dave, any thoughts on my original question? My thread kind of got hi-jacked. Not much, but since you ask: -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Saturday, October 06, 2012 9:52 AM To: openssl-users@openssl.org Subject: Best practice for client cert name checking 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. Whatever you, or your users/boss/customers/etc., need. The technical question is do you use -- that is, have your clients use -- public CAs (like Verisign etc.) or a CA that you control (operate or contract with)? If the latter, maybe you can limit issuance so that any cert issued by this CA and not revoked is a good client. (Although for openssl revocation checking to be accurate, either you must have some method to update CRLs often enough or you must implement OCSP.) 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. For public certs you may want CN (Common Name) as well as or even instead of O (Organization). 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? I wouldn't. In much of today's internet IP addresses are not very stable at identifying machines, and even less so people. But it's up to your users/etc what they need, or want. FWIW, I work in a back-end environment where the systems that connect are relatively few and very stable, though distant, so we just have our own CA which issues certs to only valid clients. Your situation is likely different. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
From: owner-openssl-us...@openssl.org On Behalf Of Charles Mills Sent: Monday, 08 October, 2012 07:47 Dave, any thoughts on my original question? My thread kind of got hi-jacked. Not much, but since you ask: -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Saturday, October 06, 2012 9:52 AM To: openssl-users@openssl.org Subject: Best practice for client cert name checking 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. Whatever you, or your users/boss/customers/etc., need. The technical question is do you use -- that is, have your clients use -- public CAs (like Verisign etc.) or a CA that you control (operate or contract with)? If the latter, maybe you can limit issuance so that any cert issued by this CA and not revoked is a good client. (Although for openssl revocation checking to be accurate, either you must have some method to update CRLs often enough or you must implement OCSP.) 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. For public certs you may want CN (Common Name) as well as or even instead of O (Organization). 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? I wouldn't. In much of today's internet IP addresses are not very stable at identifying machines, and even less so people. But it's up to your users/etc what they need, or want. FWIW, I work in a back-end environment where the systems that connect are relatively few and very stable, though distant, so we just have our own CA which issues certs to only valid clients. Your situation is likely different. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
From: owner-openssl-us...@openssl.org On Behalf Of Jeffrey Walton
Sent: Saturday, 06 October, 2012 19:11
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.
In principle yes, but in practice most ECC uses the few parametersets
(curves) established by standards and assigned OIDs which (are used to)
identify them. In this case you need only check the OID.
Similarly for classic DSA, you have publickey y and parameters
consisting of large prime p, medium subgroup order q and its
generator g. p,q,g can be shared and could be standardized but
to my knowledge aren't. p,g for classic DH also can be standardized
and were in some cases like ssh and IPsec but AFAIK not for SSL,
and any DH for SSL is rare and static-DH not supported by openssl.
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).
Not in SSL. If you use *static* DH or ECDH, you have that key in cert[0],
which is authenticated by cert[1], and cert[1] further chained as needed.
But as above openssl doesn't support static-DH; it does do static-ECDH,
but I've never seen that used. If you use *ephemeral* those keys are
in separate messages (ServerKeyExchange and/or ClientKeyExchange) not
in any cert. If you use anonymous, again the keys are in S,CKeyExchnage
and there are no certs in the handshake at all.
Yes, ephemeral either DH-E or ECDH-E does have the advantage of forward
secrecy -- but warning, current Java's standard implementation (JSSE)
on server for DH-E uses 768-bit, which isn't adequately secure when used
much less forward. (For ECDH-E most if not all named curves are okay,
and can be limited by the client, and maybe preferred, I'm not sure.)
Other protocols can be different, but it would be impractical to get
valid certs for ephemeral keys unless you are your own online CA, and
then it really give better assurance than using a (static signing) cert
to authenticate the bare key as SSL does.
A certificate, or a publickey, doesn't actually sign anything; the
corresponding privatekey does. But a certificate can carry, and be
marked in KU and/or EKU as carrying, the public half of a privatekey
used to sign certs, CRLs, data, email, etc. Which is what people
mean when they say this, and not really confusing or ambiguous.
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On 06.10.2012 23:41 , 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. try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. The certificate can change for many reasons, some legitimate (e.g. it has expired), some others _might_ be symptom of an attack (e.g. the issuing CA has changed). The assumption behind is that the first time you connect, there is no attack underway, and you store the legitimate certificate. Again with the ssh parallel, ssh stops and shows you the fingerprint of the public key. You are supposed to verify, out-of-band, the fingerprint and then authorize to pin the public key. The criteria to do the verification are up to you. You still have the problem of deciding how to handle the case of certificate changed, but at least you know it is happening. As a parallel: we first meet and as a proof of identity I show you my Italian passport. If the next time we meet you remember me, but this time I show you a French passport, you begin to wonder. Did I change nationality (possible) or is something fishy going on? marco
RE: Best practice for client cert name checking
Dave, any thoughts on my original question? My thread kind of got hi-jacked. Charles -Original Message- From: Charles Mills [mailto:charl...@mcn.org] Sent: Saturday, October 06, 2012 9:52 AM To: openssl-users@openssl.org Subject: Best practice for client cert name checking 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? Comments? Charles __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Asking whether markets are efficient is like asking whether people are smart. pgpbBheOvp6Xv.pgp Description: PGP signature
Re: Best practice for client cert name checking
On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
Aren't you talking here about the client's validation of the server's credentials? That's useful information, but my question was about server validation of client certificates ... Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Monday, October 08, 2012 11:13 AM To: OpenSSL Users List Subject: Re: Best practice for client cert name checking On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On Mon, Oct 8, 2012 at 3:49 PM, Charles Mills charl...@mcn.org wrote: Aren't you talking here about the client's validation of the server's credentials? That's useful information, but my question was about server validation of client certificates ... It cuts both ways. Both the client and server can perform the additional validations. Jeff -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jeffrey Walton Sent: Monday, October 08, 2012 11:13 AM To: OpenSSL Users List Subject: Re: Best practice for client cert name checking On Mon, Oct 8, 2012 at 9:25 AM, Mark H. Wood mw...@iupui.edu wrote: On Mon, Oct 08, 2012 at 07:42:04AM +, Marco Molteni (mmolteni) wrote: try searching for certificate pinning. If you are familiar with ssh, it is the same concept of the StrictHostKeyChecking option (although obviously SSH and TLS are completely distinct protocols and by default SSH doesn't use X.509 certs). The idea is: with a standard TLS connection, acting as TLS client, you connect to an host for the first time and you receive its certificate. The standard TLS verifications are successful (meaning: the certificate really belongs to the host and it has been issued by a CA you trust). When the connection is closed, a normal TLS client will forget the certificate. On the other hand, certificate pinning remembers the certificate. Pinning means storing locally such certificate and associate it to the hostname you connected to. If the next time you connect the certificate has changed, a system supporting certificate pinning will warn you. I believe this is what the Certificate Patrol plugin for Firefox is doing, if you want to see it in action. This plug-in pins certificates (not public keys), and creates a lot of spurious noise on some sites (for example, Google and Gmail). It desensitizes the user. I've been running experiments on Google and Gmail for the last couple of years. If you are pinning for those sites, you definitely want to pin public keys. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
On Sat, Oct 6, 2012 at 2:52 PM, 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? Comments? You don't say what you're trying to achieve! But whatever it is, none of the above makes a lot of sense - anyone can make a cert with whatever subject and alternate names they want... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
Trying to achieve client authentication. Should I have said certificate signed by a CA known to the server? Charles -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Ben Laurie Sent: Saturday, October 06, 2012 10:38 AM To: openssl-users@openssl.org Subject: Re: Best practice for client cert name checking On Sat, Oct 6, 2012 at 2:52 PM, 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? Comments? You don't say what you're trying to achieve! But whatever it is, none of the above makes a lot of sense - anyone can make a cert with whatever subject and alternate names they want... __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
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. Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Best practice for client cert name checking
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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Best practice for client cert name checking
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 Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
