Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)

From: =JeffH <[email-masked]>
Date: Mon, 12 Sep 2011 16:53:27 -0700

> Chris Evans and I work at Google on the Chrome security team. We have
 > devised this specification for a new extension to Strict Transport
 > Security to allow site operators to "pin" certificates: UAs will
 > require that TLS connections be validated with at least one of the
 > public keys identified in the new "pins" directive in the HSTS header.
 > (Sites can pin to one or more public keys in end entity, subordinate
 > CA, and/or root CA certificates, for flexibility and disaster
 > recovery.)
 >
 > We hope that this mechanism opens up the benefits of certificate
 > pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
 > and certificate pins for sites, but the mechanism for doing this
 > (email us!) does not scale.
 >
 > We eagerly anticipate your comments, questions, concerns, et c. As you
 > can see from the Ideas section, there are some unanswered questions
 > about the behavior of UAs and hosts, and possible extensions to the
 > policy.

This is great, thanks for posting this here.

I have various comments on it I'll try to get to in the next day or so.

During HSTS's gestation, various parties have discussed potential "LockCA" and 
"LockEV" directives ostensibly having similar semantics to what you've proposed 
here (see talk slides from last few websec sessions at IETF meetings). (though 
I think recent events pretty much obviate those nominal ideas because they'd 
relied on the resilience of one's CA and the CA infrastructure (oops))

Having a proposal such as this with a bunch of the background thinking (eg 
potential deployment downsides (aka "disasters")) noted down will help us on 
our way here.

I've taken the liberty of re-formatting the document in plain text (attached), 
which will better facilitate discussion hereabouts. A next step will be to 
re-format it as an Internet-Draft and get it submitted (I volunteer to help you 
out with that).

thanks again,

=JeffH

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 10:57:22 -0700

On Mon, Sep 12, 2011 at 4:53 PM, =JeffH <[email-masked]> wrote:

> I've taken the liberty of re-formatting the document in plain text
> (attached), which will better facilitate discussion hereabouts. A next step
> will be to re-format it as an Internet-Draft and get it submitted (I
> volunteer to help you out with that).

Thanks for textifying it! I'll XMLify it today and then send it to the
list, and you can all make fun of my newbie attempts to use the I-D
document type. :) I'm sure I'll need your help to make it real.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 13 Sep 2011 12:15:34 -0600

On 9/12/11 5:53 PM, =JeffH wrote:
> During HSTS's gestation, various parties have discussed potential
> "LockCA" and "LockEV" directives ostensibly having similar semantics to
> what you've proposed here (see talk slides from last few websec sessions
> at IETF meetings). (though I think recent events pretty much obviate
> those nominal ideas because they'd relied on the resilience of one's CA
> and the CA infrastructure (oops))

<hat type='individual'/>

Jeff, why do you say that? It seems to me that if you think various CAs
are dodgy or vulnerable, but you know and like the policies of the CA
you're using, you might well want to lock into that CA.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yoav Nir <[email-masked]>
Date: Tue, 13 Sep 2011 21:41:08 +0300

> you're using, you might well want to lock into that CA.

As a customer, I have very little insight into the policies of the CA I'm using. For all I know, the actual signing may be done on a server, accessible from the Internet through SSH with the user "root" and the password "password", and then it's just an OpenSSL script conveniently located along with the private key in root's home directory.

Alternatively, it's possible that the private key is stored on the web server and accessible as http://www.exampleca.com/../ca.key

Locking yourself into a CA like that seems like a bad idea. Unlike the Dutch government and Mozilla, most customers do not have the pull to force CAs to submit to audits.

Six months ago we would not have thought that Comodo or DigiNotar were easy to hack. In the latter case, the customers of DigiNotar were left out in the cold. Without certificate pinning, they just need to spend money on a new certificate and their site is working again. With it, they are in trouble.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 13 Sep 2011 15:37:11 -0400

On 09/13/2011 02:41 PM, Yoav Nir wrote:

> the customers of DigiNotar were left 
> out in the cold. Without certificate pinning, they just need to spend 
> money on a new certificate and their site is working again. With it, 
> they are in trouble.

With *CA* pinning, DigiNotar customers are definitely in serious trouble
(which is why i asked earlier about the advantage of pinning any thing
but the EE cert).  But if they had pinned their EE certs,  they would
have been able to resist even if Diginotar had issued certs with their
same name.

So certificate pinning isn't bad in this case -- CA Certificate pinning
is bad.

	--dkg

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Sep 2011 15:06:35 -0500

Just thinking out loud here.

On 09/13/2011 01:41 PM, Yoav Nir wrote:
>
> Locking yourself into a CA like that seems like a bad idea. Unlike
> the Dutch government and Mozilla, most customers do not have the pull
> to force CAs to submit to audits.

Or not, like the Dutch government, have the pull to convince Mozilla to 
hesitate for a few days to revoke your pwned CA.

> Six months ago we would not have thought that Comodo or DigiNotar
> were easy to hack. In the latter case, the customers of DigiNotar
> were left out in the cold. Without certificate pinning, they just
> need to spend money on a new certificate and their site is working
> again. With it, they are in trouble.

When would locking yourself into a keypair be any more sensible?

PKI has long history of uncounted thousands of revoked certs, most 
probably for mundane reasons. But a large number of critical cases are 
certainly due to the webserver and private key getting pwned (like 
senate.gov).

What if attacker pwned your web server and configured it to broadcast 
HSTS for a few days, pinning you to the keypair of which they now know 
the private key?

What if they maliciously pinned you to a floundering CA?

Google is one thing, they have their own CA and even their own web browser.

Q: What kind of pinning would we recommend to our friend or family 
member who runs his business on the web?
Right now he has his domain registration and cert from GoDaddy.

- Marsh

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 13:21:00 -0700

On Tue, Sep 13, 2011 at 11:41 AM, Yoav Nir <[email-masked]> wrote:

> Six months ago we would not have thought that Comodo
> or DigiNotar were easy to hack. In the latter case, the
> customers of DigiNotar were left out in the cold. Without
> certificate pinning, they just need to spend money on a
> new certificate and their site is working again. With it,
> they are in trouble.

This is why we strongly advocate that you have a backup pin, so that
you can pivot to it in the event of any of several disasters that we
outline in the document. We are even thinking about requiring backup
pins, because they are so important. (See the Risks of Pinning
section, and the Ideas section.)

Assuming that the disaster is not one of private key compromise
(either end entity or signer), you can also recover by having your
public key re-signed by a new CA.

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 13:23:55 -0700

> So certificate pinning isn't bad in this case -- CA Certificate pinning

Not even that, really. Pinning your CA and not having a backup pin
that chains up to a different CA is the bad thing.

---

From: Gervase Markham <[email-masked]>
Date: Tue, 13 Sep 2011 13:38:53 -0700

> hesitate for a few days to revoke your pwned CA.

That is rather unfair. You make it sound like they asked, and we
complied. In truth, we relied on an assessment of the situation from
GovCERT, the Dutch CERT - who have a decent reputation. When their
assessment changed, we changed our position; whether they should have
made their initial assessment the way they did is a good question, and
one which concerned parties should ask them.

It is certainly not an obvious truth, even more so in the heat of the
moment, that a compromise of one part of a certificate hierarchy at a CA
necessarily means that an entirely different one is also compromised. It
may, it may not - that depends on the arrangement and interlinking or
otherwise of the issuance systems.

Anyway, regardless, the situation is more complex than your allegation
of back-room influence.

Gerv

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 13 Sep 2011 14:42:21 -0600

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Marsh Ray
> 

What is they compromised your DNS server and sent out bogus A records with a crazy long TTL?  

I think trying to make HSTS and TLS, protocols that rely on a private key staying secret, resilient completely against a key compromise, for all manner of attacks, simply isn't practical....

- Andy

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Sep 2011 15:58:16 -0500

> Anyway, regardless, the situation is more complex than your allegation

Yes, I believe that and apologize if I characterized it unfairly.

That was just the impression I was left with reading the various 
explanations and interpretations of what was going on over those few 
days. I'm sure they weren't very accurate.

I can only imagine how hectic that process was for the parties involved 
and how complex a decision it must have been. Please understand that 
folks like me are looking it at all through a somewhat obscured window.

Sorry again.

- Marsh

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 13:35:47 -0700

On Tue, Sep 13, 2011 at 1:06 PM, Marsh Ray <[email-masked]> wrote:

> Q: What kind of pinning would we recommend to our friend or family member
> who runs his business on the web?

They could also buy a cert from StartSSL, and keep it on a USB token
in a safe, in case of emergency. I.e., everyone who does pinning
should have a backup pin.

But, currently, we are saying this about that:

"""Deploying certificate pinning safely will require operational and
organizational maturity due to the risk that HSTS Hosts may "brick"
themselves by pinning to a certificate that becomes invalid."""

"""The disaster recovery plans described above all incur new costs for
site operators, and increase the size of the certificate
market. Arguably, well-run sites had already absorbed these costs
because (e.g.) backup certificates from different CAs were necessary
disaster recovery mechanisms even before certificate pinning. Small
sites — which although small might still need to provide good
security — may not be able to afford the disaster recovery mechanisms
we recommend. (The cost of the backup certificate is not the issue; it
is more the operational costs in safely storing the backup and testing
that it works.) Thus, low-risk pinning may be available only to large
sites; small sites may have to choose no pinning or potentially
bricking their site (up to the maxAge window). This is not worse than
the status quo."""

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 17:08:40 -0400

That is a good point.

But in the Diginotar case the CA root was revoked so that could be dealt
with by saying that a client should unpin a cert when it has been revoked
(or part of the chain has been revoked).

Another tool that we could use here is to push out an 'unpin' statement in
whatever mechanism we develop for data driven revocation.

On Tue, Sep 13, 2011 at 3:37 PM, Daniel Kahn Gillmor
<[email-masked]>wrote:

> _______________________________________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/websec
>
>

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

---

From: [email-masked]
Date: Tue, 13 Sep 2011 22:24:05 +0100

On 13 Sep 2011, at 21:35, Chris Palmer wrote:
> <snip>

What about sites which don't currently use https at all? The DNS records for theregister.co.uk were redirected the other week. An attacker who could do that could redirect to https, then set a very long max-age pin. At that point, they'd be dependent on the browser vendor unpinning affected users, right?
David

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Sep 2011 17:30:13 -0500

On 09/13/2011 04:24 PM, [email-masked] wrote:
> What about sites which don't currently use https at all? The DNS records
> for theregister.co.uk <http://theregister.co.uk> were redirected the
> other week. An attacker who could do that could redirect to https, then
> set a very long max-age pin. At that point, they'd be dependent on the
> browser vendor unpinning affected users, right?

Wouldn't they have to acquire a valid cert first? Not saying that's out 
of the realm of possibility, but...

I think you have a point. The whole premise of this is that there are 
circumstances under which some attacker can obtain such a cert. If this 
feature translates to a risk of perma-DoS for the (100.0 - epsilon)% of 
sites that don't adopt it immediately then it may be more dangerous than 
it's worth.

Consider an adversarial country like, say, Bananastan. They have an ISP 
or three, their own CA, and of course, no sense of humor.

They may one day be subject to some criticisms in the online press which 
they perceive as unfair. Or maybe something on a video sharing site is 
contrary to their customs and traditions.

So their local judge orders their local ISP to block the offending media 
provider. The ISP does this by advertising more specific BGP routes for 
the video site's netblocks(1).

Being mostly streaming data of little consequence, the video site has 
not yet set up HSTS or even has full support for HTTPS (2).

The ISP also sets the country's DNS resolvers to reply to name requests 
for the site with an IP address of a webserver where citizens can 
receive educational information(3).

To be sure they get everybody, they do something I didn't know could be 
done with DNS (4).

In order to save the the misguided users that accidentally used a 
subversive https: bookmark, the court orders the local CA to "do what it 
takes to make it work"(5).

And just to be sure the message sticks, they set a long term HSTS pin on 
this cert and/or their CA (6).

Hilarity ensues.

- Marsh

1. YouTube - Pakistan - 2008
http://www.circleid.com/posts/82258_pakistan_hijacks_youtube_closer_look
http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study

2. http://youtube.com/

3. 
http://web.archive.org/web/20060418030141/http://chinadigitaltimes.net/2006/01/image_of_internet_police_jingjing_and_chacha_online_hon.php

4. China - 2010
https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html
http://www.zdnet.co.uk/news/networking/2010/10/11/mystery-of-web-traffic-redirect-to-china-remains-unsolved-40090476/

5. [...]

6. Why wouldn't this attack work?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 13 Sep 2011 18:34:34 -0400

I think that all this pinning stuff works a lot better if there is a
mechanism that allows a return to ground truth.

Since we are developing an Internet protocol, the mechanism for ground truth
should be DNS in my opinion.

It may be impractical to require DNSSEC secured responses in every case.
There are Denial of Communication issues (DoC) and there are real
performance concerns.

If however we are dealing with a case where an exception has occurred, it
seems reasonable to me for the response to be to attempt to pull DNSSEC
records via whatever guerilla mechanisms we end up deploying to bypass
censorship.

In other words, use pinning via HTTP header to provide pinning with minimal
performance impact but solve the tricky max age issues by relying on the DNS
and DNSSEC to provide ground truth when a policy violation is detected.

On Tue, Sep 13, 2011 at 5:24 PM, <[email-masked]> wrote:

> for theregister.co.uk were redirected the other week. An attacker who
> could do that could redirect to https, then set a very long max-age pin. At
> that point, they'd be dependent on the browser vendor unpinning affected
> users, right?
> David
>
>

---

From: [email-masked]
Date: Tue, 13 Sep 2011 23:38:41 +0100

On 13 Sep 2011, at 23:30, Marsh Ray wrote:
> <snip>
> Wouldn't they have to acquire a valid cert first? Not saying that's out of the realm of possibility, but...

Yeah, but in the case that you've gained control of a domains DNS, which is what happened, how hard would it be to get a valid DV cert?

---

From: SM <[email-masked]>
Date: Tue, 13 Sep 2011 16:06:53 -0700

Hi Yoav,
At 11:41 13-09-2011, Yoav Nir wrote:
>were left out in the cold. Without

   "The DigiNotar partnership has laid down its security policy in 
action protocols
    and technical protocols. For safety reasons, these documents are 
not publicly
    available, which means that they are unavailable for inspection."

   "A regular audit is performed by an independent external auditor to
    assess Comodo's compliance with the AICPA/CICA WebTrust program for
    Certification Authorities."

People get sloppy.  Businesses get complacent.  At the end of the 
day, it is a business decision.

Regards,
-sm

---

From: Chris Palmer <[email-masked]>
Date: Tue, 13 Sep 2011 17:47:17 -0700

Hi all,

Unfortunately I didn't finish the new, XMLified rev of the document
today — you raised too many difficult questions. :) It's coming along
though. I might be able to get it to the list tomorrow, but I might
end up dedicating tomorrow to a different (but related) code-writing
effort, hence wouldn't get back to this until Thursday. But, it any
case, Real Soon Now.

Thanks again for all your comments and questions! It's been very helpful.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Sep 2011 09:17:57 +0300

> day, it is a business decision.

It's all legalese to me. I can read 180 such statements (for the 180 root CAs in Microsoft's store) and not get a sense of which one is safe enough for me. 

I don't think the average site administrator (or whoever it is who buys certificates in your organization) has better information. Besides, they tend not to put too much thought into such a small expenditure.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 09:14:04 -0400

I totally agree that this is a feasible attack. It has been seen on a very
large scale, Russia did a BGP redirect at a country level in their dispute
with Georgia.

DNSSEC on A records alone is practically worthless. There is some value but
not a great deal. Most DNS attacks have been persuading registrars to put
bad data into the system.

On Tue, Sep 13, 2011 at 6:30 PM, Marsh Ray <[email-masked]> wrote:

> Consider an adversarial country like, say, Bananastan. They have an ISP or
> three, their own CA, and of course, no sense of humor.
>
> provider. The ISP does this by advertising more specific BGP routes for the
> video site's netblocks(1).
>
> Being mostly streaming data of little consequence, the video site has not
> yet set up HSTS or even has full support for HTTPS (2).
>
> The ISP also sets the country's DNS resolvers to reply to name requests for
> the site with an IP address of a webserver where citizens can receive
> educational information(3).
>
> http://www.circleid.com/posts/**82258_pakistan_hijacks_**
> youtube_closer_look<http://www.circleid.com/posts/82258_pakistan_hijacks_youtube_closer_look>
> http://www.ripe.net/internet-**coordination/news/industry-**
> developments/youtube-**hijacking-a-ripe-ncc-ris-case-**study<http://www.ripe.net/internet-coordination/news/industry-developments/youtube-hijacking-a-ripe-ncc-ris-case-study>
>
> 2. http://youtube.com/
>
>
> 3. http://web.archive.org/web/**20060418030141/http://**
> chinadigitaltimes.net/2006/01/**image_of_internet_police_**
> jingjing_and_chacha_online_**hon.php<http://web.archive.org/web/20060418030141/http://chinadigitaltimes.net/2006/01/image_of_internet_police_jingjing_and_chacha_online_hon.php>
>
>
> 4. China - 2010
> https://lists.dns-oarc.net/**pipermail/dns-operations/2010-**
> March/005260.html<https://lists.dns-oarc.net/pipermail/dns-operations/2010-March/005260.html>
> http://www.zdnet.co.uk/news/**networking/2010/10/11/mystery-**
> of-web-traffic-redirect-to-**china-remains-unsolved-**40090476/<http://www.zdnet.co.uk/news/networking/2010/10/11/mystery-of-web-traffic-redirect-to-china-remains-unsolved-40090476/>
>
>
> 5. [...]
>
>
> ______________________________**_________________
> websec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/websec<https://www.ietf.org/mailman/listinfo/websec>
>