Re: [websec] Certificate Pinning via HSTS

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Sep 14, 2011 at 9:15 AM, Daniel Kahn Gillmor
<[e-mail]>wrote:

> On 09/13/2011 05:55 PM, Chris Palmer wrote:
> > On Tue, Sep 13, 2011 at 5:45 AM, Daniel Kahn Gillmor
> > <[e-mail]> wrote:
> >
> >> From my perspective, i see no advantage to pinning any of the CAs -- if
> >> your EE is compromised, you're sunk.  And since the mechanism provides a
> >> mechanism (and nice instructions, thanks) for transition to an emergency
> >> offline backup EE key+cert, that is all handled well.
> >
> > In the case of normal EE certificate expiration — as opposed to
> > compromise — if you are pinned to (say) an intermediary signer, you
> > can just get a fresh certificate from the same signer, deploy it, and
> > change nothing else.
> >
> > Conversely, if you had pinned to an EE, you'd need to follow a
> > procedure something like this near expiration time:
> >
> > 0. Generate the new cert.
> > 1. Change your pins directive to include the new and the old public
> > key fingerprints.
> > 2. Wait long enough for "most, surely?" of your users to have received
> > the new pins, or for their pins to expire by the normal maxAge means.
> > 3. Decommission the old EE cert and deploy the new.
>
> Actually, if your certificate policy requires key rotation at
> certificate expiry, you can generate key N+1 at any time (preferably
> early in the life of the cert corresponding to key N), and introduce the
> secondary pin at that point, without having gotten certificate N+1 yet.
>

Yep.



> It still looks to me like pinning a CA does nothing more than give them
> the chance to hold you hostage at certificate renewal time, and to
> expose you to vulnerability should the CA itself be compromised.


It gives you scaling and administrative convenience.

If you have 10,000 hosts in your enterprise network you really do not want
to have to be managing trust on a per host level. Now consider the case
where you are renting your compute power in the cloud and so the machine
instances are existing for a few hours at a time.

Any scheme that insists on only tying to the EE cert or key is going to
create a major operational headache for those sites. It is really easy to
design a scheme that is easy to administer.

It is also going to cause huge amounts of state that the client has to
manage. If you have 10,000 front end web servers you are going to need
10,000 different client keys to do the job right.


So what most of the large enterprises would likely do if they introduced any
form of security policy would be to have a private CA run up that is an
intermediate in a larger hierarchy. This is why the bogus EFF study came up
with the absurd number of 600 CAs. What they have never come clean on is the
fact that 150 of those 'CAs' are in fact merely intermediate roots tied to a
single customer that are managed in the same infrastructure as the root CA
operations.


What pinning to a CA does raise is the absolute need to have the ability to
pin more than one CA at a time.

> Again, that's fine and one size does not fit all.
>
> Sure, one size does not fit all, but it looks like the document is
> (reasonably) trying to outline some common patterns of reasonable
> behavior to encourage best practices.  I still don't see any best
> practice that involves pinning to a CA unless that CA is itself under
> the control of your own organization.
>
> I recommend that the draft make this explicit, to avoid encouraging
> system operators binding themselves even more tightly to a CA by
> misapplication of this mechanism.
>

There is certainly a difference in the risk factor here between pinning in
the browser and CAA as currently specd (i.e. without the client enforcement
capability). [I originally wrote big, but thinking it through, maybe not so
much]

CA issue of certs is never a 100% automated process. There are some cases
where automated issue is possible but there are inevitably exceptions.

CAA does not prevent a CA issuing a cert, it merely triggers an exception.
So the CA that received the failed application is going to circle back to
the customer and ask what is up. If the CAA record was inserted maliciously
or without informed consent then the customer is going to be mighty peeved
with their old CA and likely contact slashdot with a nasty story.


If there is client enforcement of the records then there is a potential to
use them maliciously.

But even so, I can't see this being much of a practical concern. The main
value add CAs bring in practice is teaching people how to configure crypto
and install certs properly without making a mess of it. Every customer call
center I have been in the conversations you hear are salespeople walking a
customer through install for Apache or ISS.

So provided there is an escape hole from the pinning mechanism, the CAs are
going to be more than capable of talking the customer through how to untie
themselves from the attempted customer capture.

-- 
Website: http://hallambaker.com/