Note: All of these are things and I found and are irked by.
The first example is etcdadm, an awesome tool for building etcd clusters. etcd builds on top of mutual TLS auth. Sadly, etcdadm makes the assumption you should copy your CA private keys everywhere. (2/n)
Conversation
This is obvious if you read the README (github.com/kubernetes-sig).
etcd itself does not have this limitation, but this tool makes the assumption handling private keys and and designing a PKI this way without a second thought. (3/n)
1
4
Sometimes these assumptions are less obvious. In HashiCorp Packer (a helpful VM image creation tool), the tool does not provide a mechanism for verifying SSH host keys - and instead does not check them at all: github.com/hashicorp/pack
(4/n)
1
1
3
No where in the documentation (that I could find) is this stated - it just works that way. Now, it appears that they at least support AWS SSM (a recent feature I think) - but looking at where that function is consumed... The entire code base does that by default. (5/n)
1
2
Last example. In this HashiCorp talk (17:56 in video, "Verifying communications" section in transcript), solving SSH host key verification via Terraform and cloud-init is discussed: hashicorp.com/resources/clou
That makes both Chris and I happy. (6/n)
1
2
... up until you see the implementation. This involves creating SSH host keys on a different computer, and then shipping the keys to the Terraform resource (an AWS EC2 VM) via AWS and cloud-init. (7/n)
1
3
Now the SSH host keys are in at least four potential places:
1. The user's computer (and backups?)
2. The Terraform state file (and wherever that's stored)
3. Maybe cloud-init's logs / files saved on the VM (I would need to test this)
4. The EC2 instance
(8/n)
1
3
IMO there is a significant cultural problem here. Chris could maybe talk about this... But how are these existing, long-standing systems that should be well understood by now being so completely misused? Everyone else is building on top of these bad assumptions - (9/n)
1
3
- and the cultural message is: "just iterate, get to the next step, don't focus on details".
I don't see how that is compatible with designing secure and reliable systems. Sorry for the rant. (10/10... maybe, I might have fucked up counting)
1
3
SSHFP works well. I set it up for every A/AAAA record with a bogus value if it's something like a DNS round robin record that's not supposed to used for login.
Consider it part of the same thing as setting up DANE TLSA records for every TLS service which is each non-SSH service.
1
2
WebPKI offers no real value over DANE TLSA records beyond Certificate Transparency and only Chromium fully enforces CT as of this month when backdating certificates to bypass it stopped being possible (due to 3 year issuance when they started requiring CT). Just started working.
Firefox doesn't enforce it and Safari just started their own policy so they can't fully enforce it for almost another year (which is now the max lifetime largely thanks to Apple's unilateral decision to force it).
Never seen any non-browser bother doing real WebPKI support.
1
Nearly everything else just uses the WebPKI CAs without actually enforcing WebPKI rules beyond that. Some things hard-wire CA pins which is very risky without an out-of-band update mechanism. Few things do leaf pinning and those that do often fail to support rotation properly.
1
Show replies
I'd really like to see a proposal along the lines of "CT for DNSSEC". Distributed system to log all keys seen and thereby expose any bad behavior by signing key holders or their data sources (registrars etc).