271–280 of 290 posts
Earlier quoted context omitted.
If they put */5 in cron, a single error response will break their site and the beginning of March will also break their site.
and they will replace it with * and just do it every day just in case
IP addresses must be accessible from the internet, so still no way to support TLS for LAN devices without manual setup or angering security researchers.
Earlier quoted context omitted.
>which includes basically every entity that ships a popular web browser and every entity that ships certificates trusted in those browsers. So no one that actually has to renew these certificates. Hey! How long does a root certificate from a certificate authority last? 10 to 25 years? Why don't those last 120 minutes? They're responsible for the "security" of the whole internet aren't they?
It’s capped to 15 years. In another comment someone linked to a document from the Chrome team. Here’s a quote that I found interesting: “In Chrome Root Program Policy 1.5, we landed changes that set a maximum ‘term-limit’ (i.e., period of inclusion) for root CA certificates included in the Chrome Root Store to 15 years. While we still prefer a more agile approach, and may again explore this in the future, we encourag…
Earlier quoted context omitted.
If they put */5 in cron, a single error response will break their site and the beginning of March will also break their site.
and they will replace it with * and just do it every day just in case
Earlier quoted context omitted.
I have always been a bit puzzled by this. By issuing fixed length certificates you practically guarantee oscillation. If you have a massive traffic spike from, say, a CDN mass reissuing after a data breach - you are guaranteed to have the same spike [160 - $renewal_buffer] hours later. Fuzzing the lifetime of certificates would smooth out traffic, encourage no hardcoded values, and most importantly statistical analys…
There is a solution for smoothing out the traffic: RFC 9733, ACME Renewal Information (ARI) Extension https://datatracker.ietf.org/doc/rfc9773/
Earlier quoted context omitted.
The Internet is for End Users https://datatracker.ietf.org/doc/html/rfc8890 >Successful specifications will provide some benefit to all the relevant parties because standards do not represent a zero-sum game. However, there are sometimes situations where there is a conflict between the needs of two (or more) parties. >In these situations, when one of those parties is an "end user" of the Internet -- for example, a pe…
Can you elaborate on the context of your answer, please? I cannot connect it to anything the original post or I did write.
IP addresses must be accessible from the internet, so still no way to support TLS for LAN devices without manual setup or angering security researchers.
Earlier quoted context omitted.
> I am guessing the use case for ip address certs is so your ephemeral services can do TLS communication There's also this little thing called DNS over TLS and DNS over HTTPS that you might have heard of ? ;)
I don't quite understand how this relates?
Earlier quoted context omitted.
IPSec is terrible, huge, and messy standard that company that made it took 20 years to stop getting CVE every year
But the very nice thing about ESP (over UDP or not) is that it's much simpler to build HW offload than for TLS. Using the long ago past as FUD here is not useful.
This is fact, not FUD.
Microsoft has had multiple RCE vulns in their ipsec stack in the last two years.
The big vendors like Cisco had ipsec vulns for decades.
These days the issues are pretty well known and documented, but it really is a bad standard.
Earlier quoted context omitted.
Can you elaborate on the context of your answer, please? I cannot connect it to anything the original post or I did write.
I was trying to explain that human people have uses for this and that should be enough. Even if there aren't a ton of for-profit uses.