Let's Encrypt AUTHZ Reuse and Eternal Account Key

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by TheDong on Tuesday October 25, 2016 @10:22AM (#12788217)

In general, you'll automate lets-encrypt. That means you'll have some file or group of files (a cronjob, systemd timer, or what have you) that's capable of producing new keys.

If an attacker can read files on the filesystem as root, then they can simply read whatever automation scripts you have and issue new certs as well.

This isn't always true (e.g. if it depends on an IAM role, they'll have to get data from the instance metadata service as well), but the point is generally true.

If an attacker has root filesystem access on a box which can issue certs, it makes miniscule difference whether they need to grab an account key or bash script; either way you've probably lost.

You could also, however, have more locked-down boxes which issue certs, encrypt them for their intended hosts, and transport them over, at which point all of your host boxes no longer have account keys to worry about.

You could also encrypt-and-ship the account key from the box to elsewhere, and then remove it.

Frankly, you're making a lot of fuss about absolutely nothing.

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by zaroth on Tuesday October 25, 2016 @10:49AM (#12788447)

If you have to authenticate the domain every time, there's a good chance you capture that specific HTTP request traffic and log it to another server which isn't compromised. You now have an audit trail of the cert being issued and you have a chance of catching it.

If the account_key "walks away" and within 90 days they can get a cert without anything hitting your server, you have no audit log of the certificate being issued and are less likely to know your TLS is owned.

So if I understand correctly, the account_key is an unnecessary risk with very little return. (see my other post). I just immediately delete it every time, I don't see the point of keeping it.

Even key revocation does not require the account key, just the certificate private key. So really, what is the point? Unless there's something you actually need the account_key for... I feel like this was a failure to KISS.

EDIT: Mentioned downthread, there are also Certificate Transparency logs which can help you catch an unauthorized issuance, but that's not going to let you wire up an instant SMS through Twilio on every domain validation.

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by pfg on Tuesday October 25, 2016 @10:56AM (#12788510)

With the stolen account key scenario, you still get an audit trail through Certificate Transparency, as Let's Encrypt logs all certificates they issue.

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by lftl on Tuesday October 25, 2016 @12:04PM (#12789045)

> Even key revocation does not require the account key, just the certificate private key. So really, what is the point? Unless there's something you actually need the account_key for... I feel like this was a failure to KISS.

Can you revoke with either one? If someone steals my account key, and creates a new certificate private key do I have no way of revoking that since I don't have the new certificate private key?

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by pfg on Tuesday October 25, 2016 @12:09PM (#12789076)

Yes, both keys can be used to revoke, so as long as you still have either the account key or all certificate private keys, you're good.

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by dc352 on Tuesday October 25, 2016 @10:29AM (#12788277)

The difference is that I need to access your file system only once to get your account key. I need permanent access to exploit your automation.

Attackers can also scale revenues, potentially, by selling account keys to third parties.

[ Parent | on HN ]

Re:Let's Encrypt AUTHZ Reuse and Eternal Account Key by TheDong on Tuesday October 25, 2016 @11:23AM (#12788717)

For most types of automation they only need to access your filesystem once as well, but accessing the filesystem as root once also implies they can again (albeit at increased risk of detection).

Your second sentence is pure FUD imo.

[ Parent | on HN ]