The growth of Let’s Encrypt is phenomenal – 7 million certificates in
last four months. The remaining hurdle for automation is verification of
domain ownership. Well, actually it is NOT true. We were doing syntax
testing – hoping to get the right kind of verification error … only to
discover we have been successfully verified without providing any
information. … url to post
You can easily deactivate the autorizations if you want to.
Well, if you follow best practice and keep the account key off of hosts that have Internet-reachable services and deactivate your auths after cert issuance, this doesn’t affect you at all.
That may require some skill, though, not the hold-my-hand approach that’s driven forward so carelessly. To me it’s just proof again that ease and security don’t go well together.
There’s certainly validity in pointing out the powers of the account key but there are a couple things I would clarify:
- As @serverco mentioned you can deactivate authorizations at-will. There’s nothing preventing a client from doing this immediately after a certificate is issued.
- Another confusion is that the authz reuse feature linked by the author doesn’t actually have a material impact on the mismatched expectation they describe. You could issue a new certificate using an existing valid authz w/o solving a challenge before this feature existed. The reuse feature only addressed cases where the client asked for a new authz/challenge for a domain even though there already was a valid authz for that domain associated with the account. It was an optimization and did not change any security properties of the protocol or domain validation
- The post originally said authz’s were valid for 300 days and we were increasing it. That’s since been updated to say the validity is 90 days and we are decreasing it. That’s more accurate to be sure, but as of last Thursday it’s now 60 days! Our goal is to eventually reduce this towards 7 days.
- Using cached domain authorization for issuance isn’t specific to Let’s Encrypt
Other CAs do this as well but with less visibility/control into the mechanics.
I think the strongest take away from this post (for me at least!) is that we could do a better job explaining these aspects of ACME and Let’s Encrypt to help avoid confusion. I’ll spend some time thinking about the best way to accomplish this with respect to authorizations and the subscriber account key.
2 Likes
I guess that was one of the points I wanted to make - somehow (I don’t want / can’t to tell you how) define “best practice” as mentioned above.
Another one is around decisions what should be default behaviour and what should be explicitly enabled by users. I would think it’s more logical to “consume” authorization upon certificate issuance to be the default behaviour - but I don’t know what are most common use cases.
I don’t agree that it was a general knowledge that one could request certificates from random gear. But hey, I’m not an expert on letsencrypt.
If you’re attacker - how big a window do you need to exploit a valid authz - a months, week, day? I would think that a couple of hours is more than enough in most cases (minutes if deployment is automated). In fact, I’d expect attacker to issue rogue certs immediately after the genuine ones as it should prevent unexpectedly timed (or missing) reminder emails.
But why would they do that, when they also have access to the certificate private key, which is valid for just about as long (or even longer now) and which doesn't carry the risk of being detected via Certificate Transparency (since the certificate in question was already logged and is - presumably - authorized by the domain owner)?
I do agree that it makes sense to use a relatively low value for the authorization lifetime, but I don't think this is really A Big Deal. Here's some other things an attacker could do (with a typical web server configuration) if they're in a position to obtain the account key:
- Steal the certificate private key and use that for MitM attacks to avoid any kind of detection via CT
- Pass a new domain validation challenge and request a new certificate from Let's Encrypt
- Obtain a certificate from any other publicly-trusted CA, with certificate lifetimes up to 39 months, and authorization lifetimes up to 39 months as well (which means they could theoretically get valid certificates for your domain for up to 78 months!)
With that in mind, allowing authorizations to be reused for short periods does not add any significant risk, in my opinion.
1 Like
First of all guys - I absolutely admire what you're doing! I believe letsencrypt is one of the best security projects I can think of. I want to state this here as anything that follows are thoughts of mine trying to initiate a discussion about making letsencrypt better - and I'm an outsider with very limited visibility of issues you're dealing with!
that is true only if the attacker has permanent access to the server. They don't need this if they can get the account key, which is not time-limited - as far as I understand the mechanics of this.
Not sure how this works for non-security savvy administrator. I had an impression that he/she would have to actively check for any attacks. I absolutely like it! But you have 5,000,000 valid certs, how many admins are likely to be aware of this :slight_smile
My parents taught me to measure myself against the best 
This point is only partially valid. You're getting bloody big and as you have to automate everything. So you're definitely the best target currently.
But the main reason? Issuing a rogue certificate is free -> attackers can scale exploits very, very quickly.
A cheapest 39 months SSL cert will cost me >£20 and I'm likely to leave a money trail behind. A simple use of letsencrypt's account key from a rooted web cam is harder to trace.
1 Like
I don't see this scenario happening in practice. If you have root on a server, you're not going to use that only to steal the account key. You don't even have to bother attempting to hijack traffic to MitM with your new certificate (which is a significant hurdle), just take everything from the server as it comes in.
If you don't monitor CT, the account key issue is the least of your problems (more on this in the next paragraph).
The point I was trying to make here is that none of this account key business matters if you don't monitor CT because the attacker can just get a certificate from any CA that is valid for up to 39 months. Even if that CA does not reuse authorizations, you'll be MitM'able for 39 months, and the attacker only needs root for a minute or so to get that far. Let's Encrypt is not the first free CA, and not the last remaining free one either - even with WoSign and StartCom being distrusted by some root programs, you still have Comodo who issue free certificates through partners (CloudFlare, cPanel) and Symantec with a reseller program that includes free certificates. I expect that list to keep growing, so I don't think free vs. paid should be something we concern ourselves with when we look at risks for the Web PKI.
I have seen too much to foresee future based on my beliefs. All we can do is to do our best to get ready as only the time will show which threats were credible.
I rest my case. Good luck!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.