Hmm. I am sympathetic to TCM’s design because it avoids moving private keys and having more copies of them than those needed for the system to function at all. Nearly everything in the PKI is safe for everybody to see, but the private keys absolutely must be protected.
Of course with a central validator, bad guys who control the validator (even only briefly) could issue themselves brand new certificates for any private key they like, they don’t need to steal your keys. So, even with TCM’s design it’s still very, very bad for bad guys to get control of the central validator.
However, with Certificate Transparency (and assuming you either pay for or perform yourself some check for unexpected issuance) the new certificates would be detected, whereas if your private keys are stolen there is no way to be alerted specifically about that (intrusion detection systems might catch intruders regardless of what they were doing, but I mean here particularly the fact that the keys were copied)
Of course we can worry too much - a full-blown hardware security module in a No Lone Zone facility with armed guards is an option if you’re a bank or military site, or indeed if you’re a Certificate Authority (armed guards may not be permitted for civilians depending on your local legislation), but most of us can assume our likely attackers are just bored teenagers or criminals looking for an easy pay day. In this case your big problems are going to be crappy passwords, out-of-date security software and so on.
Yes, but the attack surface of the validator is absolutely tiny, compared to a normal server that actually uses the certs. The validator has just 22/tcp (with no login capability, just SFTP), where every other server almost always has 22/tcp for logins + something else that is backed by complex code.
Umm, yeah, mostly. What I really meant was login to the accounts that handle all the cert business. I think OpenSSH as an attack vector for unauthenticated clients hasn’t been a thing for ages, let alone getting root access (which you’d need to get the ability to answer DNS queries from that box, which is what this really is about).
But either way, you always have those scenarios on both validator and normal servers, with the normal servers always running much more (potentially vulnerable) code exposed to the world.
Someone stealing your private keys is a much more likely scenario than someone getting into a position where they can issue certs on your behalf freely.
I think wordpress ‘helpfully’ replaces tabs with spaces. Either way, nsupdate doesn’t care about leading spaces from my experiments, so shouldn’t be a problem.
In reality, the best practice is that you don’t even allow ports through that are ‘sensitive’ except for a known, trusted IP range. This reduces the risk considerably.
that is of course, if it’s possible. when you need to administrate a server from home (dont ask me why) which usually has a dynamic IP (and with IPv6 privacy extensions it gets even crazier) you can say goodbye to the IP lock.
Eh - not an issue for me - I get a routed range of both ipv4 and ipv6.
There is nothing saying that the dynamic DNS server can’t be the same one hosting your domain - but to stop things tinkering with the main zone, you can define a different zone file and allow it to be dynamically updated - but I leave that as an exercise to the reader…
Yup - there’s a million ways to get a non-core DNS server to do this - especially if you consider port forwarding, up tunnels, etc etc etc. That makes it very flexible…
