Blast Radius & Certificate Constraints

Loading...

Experienced security practitioners know that key management is fraught with risk. And systems that build on secure key management, like internal TLS deployments, inherit these risks of key compromise and exploitation. By designing systems with “blast radius” in mind, it is possible to contain these risks. Fortunately, internal certificate authorities have some unique but little-known properties available for shaping the “blast radius” to reduce operational risk.

Key Management

Key management is hard because it requires both strong technical design and operational expertise, and also carries high risk. These two characteristics (complexity & hazard) together make these systems expensive to operate. For cloud providers, the margins on key management services are enviable, but the value capture is easily justified given the costs & risks of handling key management in-house. And competition between cloud providers and others in the market is driving costs down.

Systems that build on secure key management, like internal TLS deployments, are cheaper today because of the shift to the cloud, but still carry similar levels of risk. Root key exposure is catastrophic. And lateral movement is assumed. In today’s operating environment, the risks of compromise & exposure are much greater than the operational cost for internal TLS deployments. Addressing and reducing the risk in these systems is a more effective way to further reduce their cost.

Blast Radius

The AWS team has popularized the term “blast radius” as the consideration of impact on a larger system due a failure of a smaller portion of the system. Loading.... These same principles work just as well when designing secure systems with failure as a forethought. In the security case, this upfront consideration makes it possible to quantify and reduce risk.

In recent years, there has been a push for cryptographers to design protocols with key compromise as an inevitability. Loading... is one of the most well-known protocols designed for cryptographic resilience. It introduced the novel Loading..., which provides recovery from key compromise and forward secrecy. This limits the blast radius of device compromise for Signal users to a portion of their messages instead of their full history, past and present.

WebPKI and Public CAs

In the world of WebPKI and certificate authorities, the Loading... (CT) protocol was conceived in an effort to minimize the blast radius of Certificate Authority (CA) compromise. When a CA exposes a signing key, the key can be used to issue publicly trusted end-entity certificates until the corresponding CA certificate is revoked or removed by the root store operators. Likewise, if a CA is fooled into mis-issuing a certificate, the bogus certificate can be used for impersonation until it is detected and revoked. But detecting improperly issued certificates is a difficult problem, since there is no central service involved when setting up TLS connections.

Certificate Transparency was created with the goal of improving detection of compromised or misbehaving certificate authorities. CAs publish an append-only audit log of all certificates issued by the CA, and these logs are monitored for suspicious certificates. When a certificate authority is fooled into forging a certificate, the certificate will show up in a CT log where it can be detected and quickly revoked. Vice versa, if a browser is presented with a certificate that does not have a corresponding entry in the issuer’s CT log, this is a strong indication that the issuing CA has been compromised. To date, Certificate Transparency has been very effective at scoping the blast radius of CA compromise and certificate mis-issuance.

Internal CAs

However, behind the firewall, Certificate Transparency isn’t so helpful at detecting CA compromise and certificate mis-issuance. Because internal CAs are typically used by a single organization, other organizations have no incentive (or even ability) to monitor their internal CT logs and certificates used internally by an organization. Compared to regular ways to audit an internal CA, CT logs do not offer anything extra to scope blast radius. However, there are some parts of X.509 & Loading... not available to public CAs, that can be used to scope blast radius for internal TLS deployments.

Name Constraints

Loading... defines the name constraints extension for CA certificates. These name constraints allow a CA certificate to encode the set of FQDNs DNS names and CIDR address ranges that are permitted (or excluded). It’s a bit like the Loading...: the CA certificate self-selects the namespace for all certificates it issues.

If an end entity certificate contains a common name or Subject Alternative Name that does not match one of the issuer’s (or issuer’s issuer, and so on) name constraints, clients will reject the certificate when attempting to validate it. Loading....

For example, we have a root certificate with a permitted name constraint of  .mycorp.it, and two subordinate certificates with the respective name constraints for the staging .stg.mycorp.it and production .prd.mycorp.it environments. If the staging CA were compromised, the attacker could issue certificates for both the staging mysrv.stg.mycorp.it and production mysrv.prd.mycorp.it environments, but only the staging certificate would be valid since the production dns name would not match the staging CA’s name constraint. Name constraints used in this way will scope the blast radius of key material compromise to a single environment.

Name constraints can also eliminate man-in-the-middle certificate attack surface area. In the previous example, if the root certificate had no name constraint and the signing key were compromised, the attacker could issue a certificate for any domain name–even “gmail.com” or “packages.ubuntu.com”. Any internal systems that trusted the root certificate would in turn trust bogus certificates presented by the attacker. But with the name constraint in place, the attacker could only impersonate subdomains under the internal company domain *.mycorp.it.

Path Length Constraint

Loading... (pathLenConstraint) as part of the basic constraints. Path length is an optional unsigned integer that indicates the number of CA certificates allowed in the certificate chain. For example, a path length of zero only allows end-entity certificates to be issued, while a path length of one would allow one more level of subordinate CAs.

The path length constraint can be used to reduce the risk of certificate mis-issuance by a CA certificate. For example, an attacker that manages to fool the CA into issuing a bogus certificate, but is otherwise unable to access the signing key of the CA. If the attacker is able to obtain a CA certificate (with the cA field set), it can in turn issue bogus certificates without needing to fool the CA again for each new certificate. This is effectively the same as compromising the CA’s key material. But a CA with a path length constraint of zero will neutralize these bogus subordinate CA certificates because no client will validate the bogus subordinate (even if its cA field is set).

Anchor

At Anchor, we build and operate internal TLS deployments on behalf of our customers. All CA certificates we issue (both root & subordinate) always include name constraints and path length basic constraints. This reduces our customer’s risk to key exposure and certificate mis-issuance, and allows them to scope the blast radius of incidents to individual environments.

You can Loading... and start using Anchor in your local development environment today. And for staging and production environments, Loading.... For more details about what we’re building at Anchor, Loading... and join our Loading....