Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rate Limits

letsencrypt.org

Post reply on HN
Print view View original

81–90 of 121 posts

Re: Rate Limits

#81

Post by Someone1234 »

OriginalPenguin wrote: post #60
eximius wrote: post #50

For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains - a single server you control which hosts one (or more) website(s). All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.

> How does the 3 month cert limit stem from a much more complicated problem?

Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months.

Additionally three months offers the better theoretical security against state actors. While a 2048 bit key is normally considered to take tens of years to break, it is possible a state actor with unlimited resources could construct a quantum computer that could cut that time down significantly. If the certificate pair is regenerated every three months using a safe cryptographic source this makes breaking it likely not worth while even for a quantum computer.

Re: Rate Limits

#82

Post by [deleted] »

makomk wrote: post #69
toomuchtodo wrote: post #40

Earlier quoted context omitted.

At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.

How much does it cost to manually renew your certificate every year? How much does it cost if you forget to manually renew it, or make a mistake with one of the manual steps?

[deleted]

Re: Rate Limits

#83

Post by dredmorbius »

toomuchtodo wrote: post #40
artursapek wrote: post #34

Earlier quoted context omitted.

Automation failing once shouldn't be a catastrophe; you could renew after 30 days and issue a pager alert if it fails. Then you'd have 60 days to figure out what went wrong, manually update it, and fix the issue with the automation.

At fully loaded engineer costs, if someone takes more than an hour or two to investigate, its already more expensive than a wildcard cert.

Apples/oranges comparison.

You're comparing engineer time to the wildcard cert transaction price. You're neglecting to include the time for dealing with the wildcard cert (including manually remembering to renew that).

With process automation, you (or better: a collaboratively supported tool) gets progressively better at nailing renewals.

JoshTriplett's "renew every 30 days, 60 days to fix the problem" approach strikes me as inspired.

Re: Rate Limits

#84

Post by okket »

Someone1234 wrote: post #81
OriginalPenguin wrote: post #60

Earlier quoted context omitted.

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.

> How does the 3 month cert limit stem from a much more complicated problem? Broadly speaking Certificate Revocation is garbage. It doesn't work. So when a bad actor generates a bad certificate there's a legitimate chance that without Certificate Pinning, that Certificate will be accepted even if theoretically revoked. A three months max duration limits the potential liabilities to three months. Additionally three mo…

> While a 2048 bit key is normally considered to take tens of years to break [...]

FYI: You can renew your cert without changing the key, e.g. for mail servers and DANE/TLSA.

http://www.internetsociety.org/deploy360/blog/2016/03/lets-e...

http://www.internetsociety.org/deploy360/blog/2016/01/lets-e... (part 1)

Re: Rate Limits

#85

Post by jessaustin »

toomuchtodo wrote: post #58
finnn wrote: post #47

Earlier quoted context omitted.

The few times I've had Let's Encrypt's automation fail it's taken a few minutes, not hours, to investigate and fix. Anecdotal, sure, but I don't see it taking hours to fix

Anecdotal, but managing thousands of VMs, hundreds of ELBs, service discovery, several CI pipelines, and so on, its never a few minutes unless its a blatant misconfigured flag.

It sounds as if your organization would be a customer for a different service than the one that LE provides.

Re: Rate Limits

#86

Post by eximius »

OriginalPenguin wrote: post #60
eximius wrote: post #50

For everyone that complains about Let's Encrypt, I just want to state that Let's Encrypt solves the single largest use case for issuing certificates for domains - a single server you control which hosts one (or more) website(s). All of these issues with 3 month certs, rate limiting, and limited certs/domain stem from much more complicated problems and it isn't fair to expect Let's Encrypt to tackle those.

Wait, what? How does the 3 month cert limit stem from a much more complicated problem? The 3 month cert limit is an arbitrary limit by Let's Encrypt, and has nothing to do with a more complicated problem. They could just as easily make it 6 months or a year, but instead they chose 3 months.

If you are able to get it working once, you're generally going to be able to automate it where the 3 month limit is irrelevant. Requiring longer time horizons stem from non-standard setups.

Re: Rate Limits

#87

Post by __jal »

toomuchtodo wrote: post #16
jaas wrote: post #5

Earlier quoted context omitted.

We could very easily make the cert lifetimes one year, or anything else. We chose 90 days for the reasons outlined here: https://letsencrypt.org/2015/11/09/why-90-days.html Additionally, long cert lifetimes are dangerous because revocation is ineffective and things like heartbleed happen.

I appreciate what Let's Encrypt is doing, and have even donated, but internally at our org (as a DevOps), I cannot sell certs that expire every 90 days; $300/year for a wildcard cert is a small price to pay for 1 year expirations.

Same here. But you and I (or, more specifically, our firms) are not really the market for LE, at least at this point.

I fully expect over time for others to compete with LE, using free certs as a loss leader for other services. I also expect the NSIs and Symantecs to continue making money catering to businesses for multiple reasons, some possibly reasonable, some stupid.

Of course, LE could make themselves more attractive to firms like mine, given the automation angle - I've had cert vendors try to offer tools to do this, but they have all been terrible, broken, security nightmares, or all three. Get this part bullet proof and I can imagine companies switching right after someone forgets to renew...

Re: Rate Limits

#88

Post by ajross »

Sephr wrote: post #62

Let's Encrypt doesn't support removing subdomains from a certificate like it supports adding subdomains, so people offering per-user subdomains need to create a completely new certificate every time a user deletes their account. All it takes is 5 (or 20?) users to delete their accounts and you've used up your Let's Encrypt quota for the entire week ! Without wildcard certificates or a method to remove subdomains from…

> LE is still useless for UGC sites with per-user subdomains

Let's Encrypt is a public service, aimed at operators of individual systems who host web content or email in a casual sense, were poorly served by the complexity of getting and maintaining a TLS cert, and who empirically were basically not doing TLS.

Your posited blog host is going to be a professional or semi-professional web admin. Just call up Comodo or whoever. There's a product for that need. Let's Encrypt is not it.

In the vernacular: cry me a river.

Re: Rate Limits

#89

Post by j4cob »

michaelt wrote: post #35

I wish they didn't have the limit of 20 certs per registered domain. There are a lot of use cases this blocks - Plex's use case [1] where they issued certs for all their users; large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates); and of course using ISP-assigned hostnames like host86-186-141-3.range86-186.btcentralp…

(Let's Encrypt engineer)

> large organisations (I'm sure there are more than 20 sites run under .mit.edu sites by different teams who wouldn't want to share multi-name certificates);

This is why we've added a form to request rate limit overrides. If mit.edu wants a higher rate limit, all they have to do is ask. We're trying to strike a balance between offering a free service that works for most people, and running the risk of abuse.

Also, even if mit.edu doesn't apply for a rate limit, people can issue certificates for 20 new sites under mit.edu per week, or 1,040 new sites per year. And in fact you can see a number of such sites in the crt.sh logs: https://crt.sh/?q=%25.mit.edu&page=1 (note: loads slowly).

Re: Rate Limits

#90

Post by waterphone »

JoshTriplett wrote: post #38
toomuchtodo wrote: post #21

Earlier quoted context omitted.

The chances of automation failing is higher than the chance our SSL certs will need revocation. With that said, still a big supporter of Let's Encrypt for folks who can tolerate the constraints.

> The chances of automation failing is higher than the chance our SSL certs will need revocation. Given a 90-day duration, set up automated renewal for every 30 days, and if that renewal fails, you'll have 60 days to deal with it.

Or just do what Let's Encrypt suggests and have a cron job that runs certbot-auto's renewal command twice a day, every day? It doesn't actually renew until nearing the end of the 3 month cycle, but by having two attempts per day it will make it far more likely to go through if the network is down or something otherwise prevents it from renewing one of the times. They, of course, also will email you repeatedly as you near the end if you haven't yet renewed.
Post reply on HN