[Cryptography] On the deployment of client-side certs
thierry.moreau at connotech.com
Mon Nov 14 21:26:52 EST 2016
This is a multi-million dollar question: a workable answer might signal
a serious alternative to password-based authentication.
On 14/11/16 10:45 PM, Ray Dillinger wrote:
> In response to recent discussion on the list:
> Right now we have infrastructure in place to authenticate the host side
> of most connections. Predictably we still have massive fraud
> perpetrated through credential theft followed by use of stolen
> credentials as an unauthenticated client.
> There is a technical standard for client-side certificates, which was
> part of the original SSL specification. However, because CAs demanded
> that people pay for every certs, it was utterly ignored and never
> deployed; Homer Husband and Harriet Housewife were not going to spend a
> four-digit number of dollars (or equivalent) on a certificate, and no
> sane vendor or banker was going to require them to. Hence the
> half-fast* job of one sided authentication that has become the norm.
Some historic perspective.
The privacy question was raised early: the client certificate was to
hold the user identity and sent in the clear with SSL.
Client certificate costs were intended to fund certification
authorities, i.e. entities collecting feed and avoiding liability by all
means. No financial institution would trust such a third party.
Also, in these days where suspicion about state surveillance agenda is
fashionable, I might argue that SSL lack of privacy was a bargain
considering that OSI Network Layer Security Protocol had built-in
certificate encryption (for the technical side of this -- pointless --
arguing, see http://www.connotech.com/pract_sec_authed_dh_xchng.html ).
> This sounds like a proper use case for self-signed certs (on the
> consumer side) with pinning (on the host side) to prevent fraudsters
> from impersonating consumers.
The user mental model (even before the user interface issue is
addressed) is very difficult. The authentication capability lies in the
PRIVATE COUNTERPART of the public key found in the certificate, and the
certificate itself is at once public and privacy-threatening. I note
that your post makes no reference to the very security basis (again the
PRIVATE key). Try to explain that you might get certified for a PRIVATE
key that your device generated, or be provided a PRIVATE key along with
a certificate, or renew a certificate with either the same or a fresh
PRIVATE key, or ...
> That's within practically everybody's capability, (in the sense that
> code to create self-signed certs is all over the place and most SSL
> implementations allow certs to be used on both sides) but nobody's about
> to do it (consumers) or require it to be done (bankers, merchants, etc)
> or facilitate doing it (servers, browsers, mail clients, etc).
Instead of self-signed, I prefer auto-issued (see
http://www.connotech.com/public-domain-aixcm-00.txt ) because it
facilitates the server side configuration.
Make certificates totally meaningless except as a carrier format (SSL
compliance concern, period) for the public key matching the PRIVATE key.
> How can we change that? What can we do to make it easier to do, provide
> a transition path toward, and get pinning, certificate checking, and
> revocation list checking integrated on hosts and cert generation/use
> integrated into clients? And make it simple and easy for consumers to
> share their certs from multiple devices, reliably remove them from
> devices before loan or sale, and revoke-and-replace whenever one of
> their devices with a copy of their cert gets stolen?
I am not too familiar with pinning concept (does it apply at all to the
client side?). I prefer first party certification where any service
provider maintains its own database of trusted public keys (along with
the bank account number, hospital patient file index, or whatever
socio-legal convention for entity name applies).
I have a scheme for user enrollment with this first party certification
concept, but that's may not be applicable as a mass market solution
since the other aspects are unresolved.
Anyway in this view the user cares about the PRIVATE key, finds ways to
carry it between devices (admittedly easier said than done), and
self-issues certificates at will.
The educational challenge is enormous since almost every security expert
has been trained (more or less implicitly) to relegate the PRIVATE key
protection issue as a minor system configuration management duty (to be
isolated from the user mental model). How many security experts ever
tried to explain (e.g. to a computer-literate user audience) the very
foundational principle of public key digital signatures?
> * "half-fast" is the earlier form, as in tying something down with
> loose or wrong knots so it wasn't actually fastened (made fast);
> But it sounded like "half assed", and as 'fast' to mean secured
> has fallen out of use we rarely see the earlier form anymore.
> It seemed appropriate in this case to recall that 'fast' used to
> mean 'secure.'
> The cryptography mailing list
> cryptography at metzdowd.com
More information about the cryptography