Subject: [Acme] ACME and CDNs

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Apr 2016 15:28:03 +0200

In the context of the LURK BoF, I've been thinking about using (an
extension of) ACME to issue short-term certificates to a CDN, so
that the CDN would not need a copy of the origin server's long-term
private key. I believe that this is reasonably easy to do, but what
I don't understand - and I think the current ACME draft does not
cover well - are the security implications of CDNs in general.

Suppose I have a single server, www.example.com, that's getting
a huge amount of traffic and so I'd like to move it to a CDN. What
can I do to prevent the CDN from obtaining an unauthorized (by me)
ACME certificates for this server? Several solutions come to mind:

1. I could use a CAA record to limit issuance of certs for this
server to a particular CA and hope that it will not issue "similar"
certs to multiple accounts. But an ACME CA is not required to limit
issuance/renewal of certs for a particular name to one particular
account key. And in fact adding such a restriction would mean that
if the account key is lost, the legitimate organization would not be
able to renew the cert.

2. I could rely on certificate transparency (CT) to tell me if a
duplicate cert is ever created. ACME does not require CAs to deploy
CT. So presumably there will be ACME CAs that don't have it and the
attacker will use one of them.

3. A combination of (1) and (2) should sort-of work: use CAA to
stick to a single CA that also deploys CT. The solution is far from
ideal because it only detects but does not prevent bogus certs, and
we know how hard it is to revoke missued certs. Also, ACME does not
mandate CAA support either! On top of that, detection would not be
trivial because certs are being renewed regularly (once every 90
days, say) so one can easily miss the one bogus renewal.

Other ideas?

Thanks,

Yaron

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 Apr 2016 15:15:22 +0000

You can push the keypair from the origin to the CDN.  Another option is what Akamai does, require the origin to delegate (web) DNS to us.  This can be done in stages, of course, with www.example.com<http://www.example.com> being a cname that gets “flipped over” after the CDN is up and running.  Many large customers do that, so that they can switch across CDN’s quickly.

A new challenge that allows delegated registration – here’s signed data from the holder of foo.example.com allowing example.cdn.com to get a registration for their domain – could be interesting way to address this.

--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Apr 2016 17:23:41 +0200

But that wasn't my question. I understand how a CDN and ACME can 
co-exist. My question was how to prevent a malicious CDN from creating a 
"black" certificate for my server as soon as they control the content on 
www.example.com. The ACME draft has some text around this problem in 
Sec. 10.2, but I find it unsatisfactory.

Thanks,
	Yaron

On 04/11/2016 05:15 PM, Salz, Rich wrote:
> You can push the keypair from the origin to the CDN.  Another option is
> what Akamai does, require the origin to delegate (web) DNS to us.  This
> can be done in stages, of course, with www.example.com
> <http://www.example.com> being a cname that gets “flipped over” after
> the CDN is up and running.  Many large customers do that, so that they
> can switch across CDN’s quickly.
>
> A new challenge that allows delegated registration – here’s signed data
> from the holder of foo.example.com allowing example.cdn.com to get a
> registration for their domain – could be interesting way to address this.
>
>
>
> --
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 11 Apr 2016 10:39:39 -0700

On 04/11/2016 08:23 AM, Yaron Sheffer wrote:
> co-exist. My question was how to prevent a malicious CDN from creating
> a "black" certificate for my server as soon as they control the
> content on www.example.com. The ACME draft has some text around this
> problem in Sec. 10.2, but I find it unsatisfactory.
Right, and this is in the context of LURK, so the idea is that you are
delegating TLS termination to your CDN, but not actually handing over
your private keys. And in addition you would like to prevent your CDN
from using the fact that it can terminate TLS for your DNS name to issue
an extra certificate to itself.

I think until the CA/B Forum requires CAA implementation for all CAs,
there's no way to achieve 100% confidence in this solution. It doesn't
really matter whether the particular CA you are issuing from supports CAA.

That said, if we eventually get to a post-CAA world, your solution would
work. You could do one step better and get prevention as well as
detection if we implement Hugo Landau's CAA account binding proposal.

---

From: Alan Doherty <[email-masked]>
Date: Mon, 11 Apr 2016 23:29:12 +0100

in short if you hand control of your website content (cdn or not) hosting
or dns hosting or mail hosting
to a 3rd party 
they can obtain unauthorized certificates for the domains they control (including yours) with or without ACME
(all other year or more CAs have options requiring just a dns record or email reception)

thats why your supposed to only use the services of a third party you trust for same

this will always be an issue even if its all hosted/operated in-house
(any rouge/legit IT person could/does same, with zero knowledge or oversight from the company director/board usually)

its not really the protocols issue, as knowing which of your employees (third parties are technically in your employ)
has been authorised to request the cert or not they can never possibly programmatically tell

all they can hope to tell is :
the person requesting has been placed in a trusted position by someone within the domain owners organization, because they can add content to website/dns
(and thus is less likely to be a random attacker)

as a cdn operator who only recently added https option for all our customers 
(because of letsencrypt/acme making obtaining a SAN covering over a hundred or so disperate often unresponsive customers possible/affordable and unlikely to randomly fail due to one customer ignoring the renewal)

we would never expect them to want to restrict/control the https cert for www-or-whichevername.theirdomain 
(as it points in dns to our servers so how could they ever hope to use a cert for a connection they cannot possibly ever see/intercept)

and our cert would technically be the legit cert, if they or anyone without the ip had obtained another cert that would be technically be the forgery/black or one that couldnt be used/seen without nefarious interception of some ones internet even if they are closer to the domain owner

At 14:28 11/04/2016  Monday, Yaron Sheffer wrote:
>In the context of the LURK BoF, I've been thinking about using (an extension of) ACME to issue short-term certificates to a CDN, so that the CDN would not need a copy of the origin server's long-term private key. I believe that this is reasonably easy to do, but what I don't understand - and I think the current ACME draft does not cover well - are the security implications of CDNs in general.
>
>Suppose I have a single server, <http://www.example.com>www.example.com, that's getting a huge amount of traffic and so I'd like to move it to a CDN. What can I do to prevent the CDN from obtaining an unauthorized (by me) ACME certificates for this server? Several solutions come to mind:
>
>1. I could use a CAA record to limit issuance of certs for this server to a particular CA and hope that it will not issue "similar" certs to multiple accounts. But an ACME CA is not required to limitÂ  issuance/renewal of certs for a particular name to one particular account key. And in fact adding such a restriction would mean that if the account key is lost, the legitimate organization would not be able to renew the cert.
>
>2. I could rely on certificate transparency (CT) to tell me if a duplicate cert is ever created. ACME does not require CAs to deploy CT. So presumably there will be ACME CAs that don't have it and the attacker will use one of them.
>
>3. A combination of (1) and (2) should sort-of work: use CAA to stick to a single CA that also deploys CT. The solution is far from ideal because it only detects but does not prevent bogus certs, and we know how hard it is to revoke missued certs. Also, ACME does not mandate CAA support either! On top of that, detection would not be trivial because certs are being renewed regularly (once every 90 days, say) so one can easily miss the one bogus renewal.
>
>Other ideas?
>
>Thanks,
>Â Â Â  Yaron
>_______________________________________________
>Acme mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/acme

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 12 Apr 2016 18:14:19 +0300

> detection if we implement Hugo Landau's CAA account binding proposal.

Thanks for the pointer to Hugo's PR, I think that could be a very good 
start.

I guess we need to rely on CAA to be widely deployed, but that comes 
with the territory, as Alan pointed out - a CDN can get its own cert 
even if they're not using ACME.