Live data from Hacker News

6-Day and IP Address Certificates Are Generally Available

letsencrypt.org

261–270 of 290 posts

Re: 6-Day and IP Address Certificates Are Generally Available

#261

Earlier quoted context omitted.

> 8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout There’s your answer. 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week. 8 days would result in things getting hammered on specific days of the week.

> 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week. people will put */5 in cron and result will be same, because that's obvious, easy and nice number.

If I would use short-lived certs I would make sure to choose an ACME client that has support for ARI (ACME Renewal Information). Then the CA will tell the client when it’s time to renew.

Re: 6-Day and IP Address Certificates Are Generally Available

#262
post #244

Earlier quoted context omitted.

I chose 160 hours. The CA/B Forum defines a "short-lived" certificate as 7 days, which has some reduced requirements on revocation that we want. That time, in turn, was chosen based on previous requirements on OCSP responses. We chose a value that's under the maximum, which we do in general, to make sure we have some wiggle room. https://bugzilla.mozilla.org/show_bug.cgi?id=1715455 is one example of why. Those are ba…

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/

Re: 6-Day and IP Address Certificates Are Generally Available

#263

Earlier quoted context omitted.

> 6 days means on a long enough enough timeframe the load will end up evenly distributed across a week. people will put */5 in cron and result will be same, because that's obvious, easy and nice number.

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

Re: 6-Day and IP Address Certificates Are Generally Available

#264
post #233

Do I understand correctly: would someone have a concrete example of URL which is both an IP address and HTTPS, widely accessible from global internet? e.g. https:// / ?

The websites for DNS servers known by IP? https://1.1.1.1/ presents a valid cert although it redirects.

Out of curiosity, any other example without redirect, in which the URL stays https:// in the browser?

Re: 6-Day and IP Address Certificates Are Generally Available

#265
post #246

It's a huge ask, but i'm hoping they'll implement code-signing certs some day, even if they charge for it. It would be nice if appstores then accepted those certs instead of directly requiring developer verification.

I see how this would be useful once we take binary signing for granted. It would probably even be quite unobjectionable if it were simply a domain binding. However, the very act of trying to make this system less impractical is a concession in the war on general purpose computing. To subsidize its cost would be to voluntarily loose that non-moral line of argument.

I don't understand where the argument is. Being able to publish content that others can authenticate and then trust sounds like a huge win to me. I don't even see why it has to be restricted to code. It's just verifying who the signer is. More trusted systems and more progress happens when we trust the foundations we're building. I don't think that's a war on general purpose computing. I feel like there is this older way of thinking where insecurity is considered a right of some sort. Being able to do things insecurely should be your right, but being able to reach lots of people and force them to use insecure things sounds exactly like a war on general purpose computing.

Re: 6-Day and IP Address Certificates Are Generally Available

#266

I wonder if transport mode IPsec can be relevant again if we're going to have IP address certificates. Ditto RFC 5660 (which -full disclosure- I authored).

Is IPsec still relevant ?

It's not. What I have in mind is TLS handshake mediated ESP SA pair keying and policy. Why? Because ESP is much much simpler to implement in silicon than TCP+TLS.

ESP is stateless if using IPv6 (no fragmentation), or even if using IPv4 (fragmented packets -> let the host handle them; PMTUD should mean no need for fragmentation the vast majority of the time). Statelessness makes HW offload easy to implement.

Re: 6-Day and IP Address Certificates Are Generally Available

#267
post #246

Earlier quoted context omitted.

I see how this would be useful once we take binary signing for granted. It would probably even be quite unobjectionable if it were simply a domain binding. However, the very act of trying to make this system less impractical is a concession in the war on general purpose computing. To subsidize its cost would be to voluntarily loose that non-moral line of argument.

I don't understand where the argument is. Being able to publish content that others can authenticate and then trust sounds like a huge win to me. I don't even see why it has to be restricted to code. It's just verifying who the signer is. More trusted systems and more progress happens when we trust the foundations we're building. I don't think that's a war on general purpose computing. I feel like there is this older…

Technologies cannot be normatively evaluated without considering the power structures they facilitate.

Consider secure boot; assuming it's properly implemented, could defend against an entire class of attacks—evil maid: if a third party physically compromises your machine while you're away to install malware, you'd be alerted or stopped from booting the modified image. This is a technical statement. Now whose keys are actually trusted to sign these images? The answer is whatever power dominates in the supply chain: Microsoft, on desktop devices, and the vendor on mobile.

In the case of Microsoft, the public indignation eventually forced them to open this system up, letting the poweruser delegate their agent freely and without manufacturer's coercion. But what about Android, where the natural market forces did get the upper hand: most phones remain locked from disabling secure boot, even fewer let you enroll your own keys. They result is that most Android phones cease security updates only a few years after manufacture, the vendor's own software riddled with obvious faults (like filling a user-inaccessible partition with logs that never get wiped, even after factory reset) and known CVEs, yet nevertheless remain attested as secure for high-assurance applications like banking, as determined by Google. This hypocrisy isn't accidental: the system's real aim was not to secure the user, but to secure its monopoly, instrumented by privileged Google Play Services, harvesting data beyond what any SDK can.

I myself regularly rely on attestation—my phone runs Graphene OS and my laptop self-signs its kernel for secure boot—but I recognize that these technologies in themselves are predisposed to misuse by anti-competitive corporations and repressive regimes.

Imagine government ID backed app signing became the norm for app stores. There will no longer be open-source utilities, like scientific calculators, notes, and budget planners, as they would not bear the certification fee what is effectively volunteer work, instead replaced by their ad-ridden copycats mass-produced in a software sweatshop, featured alongside or, through malicious ads, directing to assorted malware, still just as prominent as before, signed using passport details of random people off the street, taken down as late as they can, because Google enjoys a steady revenue stream from their repeated publisher verifications and AdSense spots. And that's to say nothing of censorship circumvention tools and other politically inexpedient software.

Re: 6-Day and IP Address Certificates Are Generally Available

#269
post #3

As already noted on this thread, you can't use certbot today to get an IP address certificate. You can use lego [1], but figuring out the exact command line took me some effort yesterday. Here's what worked for me: lego --domains 206.189.27.68 --accept-tos --http --disable-cn run --profile shortlived [1] https://go-acme.github.io/lego/

[dead]

Re: 6-Day and IP Address Certificates Are Generally Available

#270
post #236

What is a good use case for an IP address certificate for the average company? Say, e-commerce or SaaS-startup?

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.
Post reply on HN