[revertts]

It's a very good question! Figuring out security for these remote racks is one of the hardest parts. For some CDNs their larger POPs will be locked cages with security cameras and all, but these small deployments are significantly more exposed.

Exactly how SSL is handled (or not) varies by provider, but one thing I'll mention is that these will typically never have a cert so important that it can't be easily revoked, and the most important data will likely not be flowing across them - exposure is very limited. Using video streaming as an example, one option is to only do TCP termination for example.com (or to not even terminate that domain on the local cache, but back at your main datacenter), then use subdomains with individual certs for the local cache (eg. isp1.cache.example.com). In that case, service calls like login, retrieving the manifest, etc. are secured by the certs you're keeping in your primary dc, then the manifest has a set of https://isp1.cache.example.com URLs pointing to the local cache only for video segments.

Another tricky aspect is making sure that your main network treats them as untrusted so someone with local access can't use it to get a foothold into the rest of your infra.

[regecks]

>these will typically never have a cert so important that it can't be easily revoked

I think this is specifically addressed with the introduction of TLS Delegated Credentials[1]. This allows the CDN edge to use a very short lived credential in the place of the certificate's private key.

It's already supported in evergreen browsers and in certificate profiles from commercial CAs like Digicert.

1. https://tools.ietf.org/html/draft-ietf-tls-subcerts-06

[revertts]

Yup! Some of the names on that draft were people who have previously worked on building these sorts of edge racks, so their experience with this infra helped shape the proposal. It'll be great once it's broadly supported, but that's going to take awhile (or depending on your client mix, an eternity).

[jjeaff]

Correct me if I'm wrong, but my understanding is that revoking a certificate is usually not a very effective mitigation for a stolen cert. Since many clients don't check for revocations.

[revertts]

That's correct - 'revokation' in this case would likely involve rolling the DNS name to something different. Since these racks tend to have precise targeting (ie. not dns gslb) and non-user facing names, there's more flexibility.

The delegated creds draft that regecks mentioned is also relevant. That will make issuing lighter weight, so this sort of 'burn the cert and roll the DNS name' procedure becomes significantly cheaper operationally.