I initially had my doubts but I think 90-days is a pretty good lifetime; it gives plenty of time to get your automation setup correctly, and if you’re renewing monthly as recommend then that’s two attempts to renew before you need to start worrying about expiration, while still giving <30 days to resolve any issues that weren’t fixed earlier.
The recommendation is to renew after 60 days, not monthly.
wow looks like the poll has changed it’s balance.
to be honest I like this.
1 Like
The thing is that having the option to have longer-lived certs hurts “revocability”. Consider any of those situations:
- The server hosting the service got owned and I made the LE client issue me a long-lived cert.
- I managed to make LE issue me a cert, for instance through subverting either BGP or DNS.
- My domain changed ownership shortly after I got a certificate issued.
In all those cases, I (as an adversary) gain an advantage by being able to ask for long-lived certs.
In other words, adding that option hurts security.
The thing is: Authorizations are already valid for about a year, not just three months. You can reissue certificates without solving the challenges again for a year.
Yes, but revoking an authorization is a problem that LE can solve, since everything happens on LE’s side.
On the other hand, time has proven that revoking a cert is basically impossible, since there are way too many “innocuous” OCSP/CRL failures happening.
true that.
the revocability is a fact but if the CA could set a flag “enforce OCSP/CRL checks” then this problem could be solved.
but also when you get certs 6 times a year the CT databases will get really bloated.
1 Like
Right, but that's not something Let's Encrypt unilaterally can make happen. Until that's how things work, they should make decisions based on how the ecosystem works today - and that currently means revocation is broken, and short certificate lifetimes mitigate that to a certain degree.
CT is designed to scale, and it's a distributed system. The write path is basically append-only and the read path is essentially sequential. With those access patterns, scaling is basically a storage problem, and storage is cheap.
the revocability is a fact but if the CA could set a flag "enforce OCSP/CRL checks" then this problem could be solved.
OCSP-Must-Staple is a beautiful solution, but it completely fails to gain traction, and LE has to live with existing implementations.
Without OCSP stapling, making OCSP/CRL hard-fail is simply going to create widespread breakage...
I don't get your point about CT, which doesn't do revocation and doesn't require people to download the entire list anyhow.
1 Like
well OCSP must staple is intresting but only if your server/appliance/whatever supports OCSP stapling in the first place.
that’s why I think an “enforce check” flag would be better.
Except that, as repeatedly explained, making OCSP hard-fail is a no-go: even assuming perfect reliability on the side of the OCSP server, somewhere between 1% and 10% of verification attempts will fail due to IP connectivity or DNS issues client-side[ref. needed].
When you also start to consider threats against the OCSP service too, because DoSing it results in a DoS of all services enforcing OCSP checks, this becomes a very thorny issue.
Moreover, it might be unacceptable for quite a few users to be down whenever LE is down, or when their internal Internet connection is down (think Intranet services, for instance).
Lastly, your “enforce check” flag also requires to have TLS stacks that understand it, and doesn’t actually provide security if it is an optional mechanism (i.e. if I can request certificates to be issued without that flag).
For a longer but more comprehensive explanation, I will refer you to the inimitable Adam Langley.
1 Like
well must staple is also optional
for pretty much similar reasons:
clients must understand it.
if OCSP is down while the server wants to fetch it, well forget it
the server doesnt support OCSP stapling which might especially the case when you are either talking about non-http servers or services that bring their own server on their own port like qwebirc or whatever
That means it's completely useless. Revocation is used when your key is compromised. In order to make use of a stolen key, an attacker must be able to MitM the target. If the attacker is able to MitM the target, he can block OCSP queries.
That is the crux of any optional online verification. You can't have an "enforce" flag and then say "well forget it if it's down".
1 Like
well must staple is also optional for pretty much similar reasons:
clients must understand it.
That doesn't mean it needs to be optional, since clients that do not understand it will ignore it.
(Same as your “must check” flag).
if OCSP is down while the server wants to fetch it, well forget it
The main difference, and what I think you are failing to grasp, is that stapling only needs the OCSP service to be available once in a while from the server, and ACME itself makes the very same assumption (you need to talk to the ACME server to renew the certificate, obviously).
On the other hand, your “hardfail” flag requires the OCSP service to be available all the time, from all clients.
the server doesnt support OCSP stapling which might especially the case when you are either talking about non-http servers or services that bring their own server on their own port like qwebirc or whatever
Those service also have hosts of other issues, starting with obsolete TLS versions (or even SSLv3!) and ciphersuites, and <SSL vuln of the month with a cheesy name>. Also, nothing prevents the sysadmin from using any other kind of TLS front-end (usually as part of their reverse-proxy).
To sum it up, having a “OCSP hardfail” flag has the following drawbacks, compared to “OCSP Must Stable”, for no apparent advantage:
- higher load on the OCSP infrastructure;
- much higher reliability requirements on the OCSP infra and the client connectivity, which brings a notable DoS vector;
- requires a TLS extension that doesn't even exist as a draft (whereas Mozilla and others have at least experimented with Must-Staple).
In any case, this seems off-topic in this thread and I think you should have a look at Adam Langley's note, linked earlier.
by the way I dunno whether you know it or not, but OCSP hardfail is already implemented in some certs, the EVs (you dont wanna know how often the WoSign website failed for me.
okay LE doesnt do EV but it’s plain about the hardfail concept which already does exist.
also obviously I think that hard fail and staple should be used together but if somebody cant staple (shared hosting is probably another nice example) and still would really want that everyone gets the certs then he should be able to enforce hardfail.
also a hardfail flag wouldnt increase the load on the OCSP much because all clients that do OCSP are already doing it. a hardfail doesnt suddenly increase the number of OCSP checks.
1 Like
also a hardfail flag wouldnt increase the load on the OCSP much because all clients that do OCSP are already doing it. a hardfail doesnt suddenly increase the number of OCSP checks.
Wrong. Chrome and Chromium do not perform OCSP checking by default.
Please, read up on the things you were linked.
Also, you didn't address the reliability issues, and instead provided an example of why it is an issue in current deployments ...
I thought they always check but are soft fail.
I mean where’s the point in setting up OCSP if no browser checks it.
okay this is so goddamn stupid. why completely ignore the OCSP system?
why revoke at all if nobody checks it?
It is explain at https://www.imperialviolet.org/2014/04/19/revchecking.html that @nicoo linked.
In short, because it does not work as a revocation system, slow down connection, leak the list of sites you consult to CAs.
1 Like