Not when the private key is kept private.
Why? There's no risk with making lots of accounts. It shouldn't matter whether I have one account, or 500 accounts. As long as I stay within the rate limits so I don't negatively affect services for others.
1 Like
You and I might not always see eye-to-eye on many things, but here I can say that you've succinctly stated one of my largest security concerns.
I make the same argument for needing to check server-side code when it comes to installing untrusted client implementations handling private keys for certificates. This is in opposition to the (much more secure) situation where the server running the client, be it web or terminal based, does not have access to the server generating the private key and csr. This brings me to what I see as the primary dilemma:
- Install an untrusted client on my server and give it permission to create and install (and steal) my private keys. It will (hopefully) use my account private key (and hopefully not steal it too) to perform the registration, certification, and renewal processes for me. The client effectively has carte blanche to modify my csr to represent my domain however it wishes. The client will absolutely be able to decrypt my traffic.
- Use an untrusted client on another server and give it my csr, trusting that it will help me to get my certificate. It will use its own account key (and incur whatever unnecessary security risks that should not exist with proper design). At worst it should only be able to generate a broken certificate that either will not install or will not verify once my certificate management software scrutinizes it, including checking its chain with Let's Encrypt. The client will absolutely NOT be able to decrypt my traffic.
In either case, the result should be a properly installed and verifiable certificate because that's the point of PKI in the first place.
I fully agree. The problem seems to stem from Let's Encrypt giving the "account" power over new issuances in 30 days without reverification and unverified revocation privileges.
I mean, just because I can authorize my stock broker to sell my stocks doesn't mean I need to hand them my bank account.
There's a simple solution to this. Pick an open source client and review the code before using it.
1 Like
Who the hell has time for that? 
Certainly not your average website owner. That's why I wrote my own. It's only like 250 lines long (now) including my own der decoder and I know every bit, nibble, and byte of what's happening. But, I'm paranoid.
Not really, Sure I can edit a CSR and put a bunch of extra stuff in it, but Let's Encrypt won't sign it if I can't verify control (And they remove a ton of unnecessary fields, like organization which isn't applicable to DV certificates). It could also edit the key in there, but then I'd know something is up because my private key doesn't work -- so there's not much point in doing that as an attack, since it would be immediately detected.
It seems like the user is the one incurring all the risks here by not using a proper client, which keeps certificate's private key and account's private key local.
This doesn't make any sense. A certificate is a certificate, and is valid to clients for the defined list of names until it either expires or is revoked.
I have no idea what you are talking about. There is no such thing as a "broken" certificate
It seems your whole argument here hinges on the idea that all the clients are backdoored, and that your server's implementation is impervious to any form of evil doing.
1 Like
Huh? The client on another server NEVER sees the private key associated with the CSR. It ONLY sees the CSR with the public key.
I specified both to further state my point and describe best practices, they should both be kept secret. I am aware that in this case only one is.
1 Like
Not impervious, but without my server having access to any certificate's private keys I fail to see the actual risk. The only elevated permissions my server gets are from the account key, which will NEVER allow me to decrypt the client's data. Hence, security.
I beg to differ. 
I can give you a few hundred if you like. They probably will not install correctly, definitely won't verify with the CA, and are certainly useless without a matching private key installed.
They are until proven otherwise. That's called proper security.
I think something being missed here is that the account key is essential to the integrity of the entire ACME protocol ... by design. It provides an end-to-end guarantee that a third-party cannot cause a misissuance - at most they can deny the process from happening.
Or in other words, a properly implemented ACME client, keeps the entire process honest. If you get rid of it, it becomes a free-for-all.
Every part of the process relies on the privacy of the ACME account key:
- Integrity of each request is guaranteed (third-party can't substitute the CSR) because each request is signed via JWS with your account key.
- A malicious third party cannot relay a challenge token from an unrelated order (or even CA), because the ACME client will not play along, because it will always append the its JWK thumbprint, which it calculates by itself.
- The malicious third party cannot replay past requests, because nonces + request integrity.
A lot of this is discussed in the spec itself - RFC 8555 - Automatic Certificate Management Environment (ACME)
Given these considerations, the ACME validation process makes it
impossible for any attacker on the ACME channel or a passive attacker
on the validation channel to hijack the authorization process to
authorize a key of the attacker's choice.An attacker that can only see the ACME channel would need to convince
the validation server to provide a response that would authorize the
attacker's account key, but this is prevented by binding the
validation response to the account key used to request challenges. A
passive attacker on the validation channel can observe the correct
validation response and even replay it, but that response can only be
used with the account key for which it was generated.
Even you don't personally like that ACME accounts have so much power, that's how the protocol is written, and isn't going to change. Most you can do is adjust your practices accordingly.
I don't think this is only about authorization reuse either, though that is a very obvious and dangerous weakness of delegating power to somebody else's ACME account. I'm sure there are other, less likely but still dangerous attacks, like active/passive MITMs on the ACME channel (or in your case, your website), as discussed in the document.
That said, if you look at the way that traditional commercial CA resellers operate, it's all the same risks. So it's not like these web-based clients are so dramatically dangerous that they must not be used. I think it's more that they're much worse than the way ACME is meant to be used.
3 Likes
Canāt say that I truly disagree with what youāre saying. In principle I believe I understand the spirit of the protocol.
Other than potentially issuing unauthorized certificates during the 30 day ācacheā period or possibly revoking certificates without authorization, both of which should not be allowed anyhow, what elevated permissions does an account key gain over domains being certified? 
I guess I pose the question: why have the account at all? Seems like establishing a session key and relying upon proof of control would suffice to prevent misissuing certificates. Iām also not one to really believe in proving domain control by proving hosting control. It seems like I should be able to control a domain and point its records at hosting I donāt control if I so choose. Granted itās probably not all that common to ārent outā a domain name, but it does allow a domain owner to hand absolute control of their hosting to a developer without handing over rights to certify the domain in the process.
I suppose Iāll have to dig around in the spec more to see what I find.
A proper client should never have access to either of these things as trusting the client with your private keys should not even be necessary. As I see it, the whole purpose of asymmetric encryption is to never need to share your private keys (any more than absolutely necessary to function). Does no one ever find it strange to grant a client maintained by a CA unrestricted access to the private keys for the very certificates they generate and vouch for? Isn't that a conflict of interest and a real motivation for abuse?
Thanks so much to @orangepizza for pointing this out:
To add insult to injury, there is no universal way to check for domain expiration or last change (some registries really don't like automated queries)
Of course, and never upgrade it. There is some level of trust and network effects involved in keeping the clients safe. If I'm the only one using a client, I might as well develop my own; on the other hand, if I'm one of thousands or millions of users...
1 Like
thatās why LE doesnāt make own client: certbot is from EFF, while EFF donates to ISRG itās separate entity.
2 Likes
Thanks so much for pointing that out. I made the mistake of tying them together directly. It's at least some degree of separation.
The big question to me is the number of eyeballs monitoring the "improvements and fixes". For something high profile like OpenSSL, somebody will probably notice shenanigans. But for more niche software, how many people (not involved with the project) will check? We've all probably heard the impacts of Wikipedia pranks (and sabotage).
Of course the client should have access to the private keys. In the vast majority of cases, it's responsible for creating them in the first place. In the account key's case, it literally needs to use it in order to sign the protocol messages (which I'm sure you already know). And for those paranoid about the cert private key, most clients have an option to use externally generated CSRs. But the people who choose to use that option are by far in the minority.
It sounds like you consider a local ACME client somehow different than a web server or a crypto utility like openssl. They'll all have access to private keys. They're all just software that the user has vetted (based on whatever criteria they deem acceptable) and chosen to run. Often the choice comes down to trust. Trust in the author's intentions. Trust in the integrity of the supply chain. Trust in the long term supportability of the software.
The primary difference I see between a local ACME client and a SaaS based one is that I get to decide when the software changes. If I have a trusted version of code running on my machine, I can use it until it breaks. It requires no additional trust beyond the point in time that I chose to install it. SaaS software is completely subject to the whims of the server operator. So even if I trust the author today, I have to continue renewing that trust every single day because the software could change at any time and I wouldn't know it unless something broke. Even if the site's code is open source, I have no guarantee that the available source is actually what's running on the server. It's an inherently riskier config no matter how you slice it.
1 Like
Inherently I agree with most of what youāve very elegantly said. I do find one other big difference between a remote client and a local client:
- A remote client has access to the account key used in the process of acquiring your certificate.
- A local client has access to the account key used in the process of acquiring your certificate and the private key associated with your certificate
Therefore a local client ALWAYS has more power to do damage, so ultimately itās not just about who you trust, but how much you trust them with.