Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

Great writeup intunderflow. The question I have, though, is how this doesn't just "push" the security problem one level down.

Point being that yes, you need to ensure that your root certs are super secure and that you have a full documented, videotaped chain-of-custody. But then at some point you need to use that root cert to sign some other cert that DOES live in your infrastructure and is used to sign requests. How do you control your systems at the point where you need to use your cert (or a cert chain) to sign requests that by their nature must be connected to the Internet?

View on HN

This will probably come in a future blog post (and also I don't lead this part of secret management so I don't have all the context), but our Intermediate's mostly live in nice locked down machines in AWS (avoiding exact product names because I don't want to tread on other peoples toes)

There's definitely a much bigger risk with an intermediate on the internet, however we at least have the mitigation of being able to revoke it if it goes wonky, the main priorities I see in this space are: (1) minimising the chance of a compromise as much as possible (very clear and well defined communication channels so that as few things are open to even being poked at for vulnz over the network as possible) and (2) being ready to react if there is a compromise (revoke the cert and recover)

If the intermediate is compromised you'll need to do a new key ceremony with the root to sign a new CRL, correct? And I'm assuming every component is configured to explicitly check CRLs and fail if those are unavailable for whatever reason, right? How does it ensure that the CRL it's getting is the latest CRL including the now-revoked certificate, and not an earlier one that's being replayed?

PKI revocation as a technology is definitely not the greatest thing in the world, the best protocol at the moment is OCSP with a specifically configured Validation Authority. But even then quite a lot of OCSP implementations in modern software are configured to continue if they can't make a connection.

Fortunately, because the usage of our CAs is very tight to Monzo and our partners, we can reach out and explicitly ban a certificate from our machines (and tell partners to do the same) without too much trouble (as compared to Public CA's who have no chance of being able to do this) in addition to following normal PKI revoking procedures.

> If the intermediate is compromised you'll need to do a new key ceremony with the root to sign a new CRL, correct?

You can use Validation Authorities to avoid needing the full on root that can issue new certs just to revoke an existing one. https://en.wikipedia.org/wiki/Validation_authority

Thanks very much for the response and the writeup, really appreciate it!

Well, in that scenario, creating intermediate certificates offline, deploying them where needed, securing them with less effort than root but more effort than others, and creating actual certificates to use via the intermediate certificates should be a reasonable approach.

Reply on news.ycombinator.com