Hi infosec mastodon. Question. Whats the standard for storing the Private Key that is used in a TLS handshake? Would you store it in an HSM?
@goldbe for big sites this is tricky! Private key has to be available to tens of thousands of CDN nodes. A “networked HSM” model is common but it’s still gonna end up in ram on the edge nodes.
@briansniffen @goldbe for the small sites, the most deployed solution by far is Let's Encrypt and the associated certbot. File on disk.
@huitema @goldbe absolutely. I feel like there’s space for an HSM (TPM?) supporting those cases, as part of standard server hardware (and virtualized); the planetary scale folks have a different problem.
@briansniffen @goldbe @goldbe asks "would you store it in an HSM". I am not sure I would know how to do that for a server running on a VM in the cloud -- would need support for AWS, Azure, or the other folks. Also, I would then need the server to store credentials to access the HSM, which feels like the first turtle in a long pile...
@huitema @goldbe absolutely, but even with 15-year-old vTPM technology, you can keep someone from checking it into git or rsyncing it to their laptop. Well. Until the Azure ops staff member does it, maybe.
@huitema @goldbe same reason I like really bad MFA—not shareable—and love slightly better MFA—not phishable. TLS private keys shouldn’t be in the heap with network code. Next, they shouldn’t be on disk or in the cpu. One step at a time. :)
@briansniffen @goldbe I think this could be sold as public key computing offload. That's a major CPU bottleneck, so I could see sending a transaction from server to public key box and receiving the result as both security and perf gain. But the server will have to show creds to the public key box to get access, and that's definitely an avenue of attack.