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

6-Day and IP Address Certificates Are Generally Available

letsencrypt.org

Post reply on HN
Print view View original

181–190 of 290 posts

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

#181

Post by cpach »

stackghost wrote: post #171
xg15 wrote: post #47

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.

>so still no way to support TLS for LAN devices without manual setup or angering security researchers. Arguably setting up letsencrypt is "manual setup". What you can do is run a split-horizon DNS setup inside your LAN on an internet-routable tld, and then run a CA for internal devices. That gives all your internal hosts their own hostname.sub.domain.tld name with HTTPS. Frankly: it's not that much more work, and it'…

There’s also the DNS-01 challenge that works well for devices on private networks.

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

#182

Post by tucnak »

charcircuit wrote: post #84
londons_explore wrote: post #69

Earlier quoted context omitted.

But isn't it unnecessary to use https, since tor itself encrypts and verifies the identity of the endpoint?

For example HTTP/2 and HTTP/3 require HTTPS. While technically HTTPS is redundant, .onion sites should avoid requiring browsers to add special casing for them due to their low popularity compared to regular web sites.

What are benefits of HTTP/2 and HTTP/3 for Tor hidden service traffic?

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

#183

Post by tucnak »

rnhmjoj wrote: post #73
londons_explore wrote: post #69

Earlier quoted context omitted.

But isn't it unnecessary to use https, since tor itself encrypts and verifies the identity of the endpoint?

Yes, but browsers moan if you connect to a website without https, no matter if it's on localhost or an onion service.

Well, you're not supposed to use Tor from browsers that don't explicitly support it. Tor Browser, Brave, and I'm sure some others really wouldn't mind HTTP hidden service traffic.

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

#184

Post by cryptonector »

reincarnate0x14 wrote: post #179
cryptonector wrote: post #66

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).

Maybe but probably not. Various always-on , SDN, or wide scale site-to-site VPN schemes are deployed widely enough for long enough now that it's expected infrastructure at this point. Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which w…

You're not thinking creatively enough. I'm only interested in ESP, not IKE. Consider having the TLS handshake negotiate the use of ESP, and when selected the system would plumb ESP for this connection using keys negotiated by TLS (using the exporter). Think ktls/kssl but with ESP. Presto -- no orchestration of IKE credentials, nothing -- it should just work.

The real key is getting ESP HW offload.

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

#185

Post by phantom784 »

PunchyHamster wrote: post #130
halifaxbeard wrote: post #117

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.

I'd have it renew Monday and Thursday to avoid weekend outages.

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

#186

Post by tosti »

stackghost wrote: post #171
xg15 wrote: post #47

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.

>so still no way to support TLS for LAN devices without manual setup or angering security researchers. Arguably setting up letsencrypt is "manual setup". What you can do is run a split-horizon DNS setup inside your LAN on an internet-routable tld, and then run a CA for internal devices. That gives all your internal hosts their own hostname.sub.domain.tld name with HTTPS. Frankly: it's not that much more work, and it'…

> run a CA

> easier than remembering IP addresses

idk, the 192.168.0 part has been around since forever. The rest is just a matter of .12 for my laptop, .13 for the one behind the telly, .14 for the pi, etc.

Every time I try to "run a CA", I start splitting hairs.

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

#187

Post by reincarnate0x14 »

cryptonector wrote: post #184
reincarnate0x14 wrote: post #179

Earlier quoted context omitted.

Maybe but probably not. Various always-on , SDN, or wide scale site-to-site VPN schemes are deployed widely enough for long enough now that it's expected infrastructure at this point. Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which w…

You're not thinking creatively enough. I'm only interested in ESP, not IKE. Consider having the TLS handshake negotiate the use of ESP, and when selected the system would plumb ESP for this connection using keys negotiated by TLS (using the exporter). Think ktls/kssl but with ESP. Presto -- no orchestration of IKE credentials, nothing -- it should just work. The real key is getting ESP HW offload.

Oh I agree with it being nice, I'm just imagining more socialization oriented resistance to implementation and both large organizations and hobbyists already have answers that mostly cover the use cases even if not exactly as cleanly. Moving node to node encryption to an accelerated implementation of transport mode would be great, but if you're already using TLS I can see people just sticking in TLS versus hoping both ends had the necessary handshake->ESP path working, plus people are more experienced with existing troubleshooting, etc.

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

#188

Post by bflesch »

cpach wrote: post #174
bflesch wrote: post #167

Earlier quoted context omitted.

I hope so, but can we really be sure that .se or .de would still work in such a scenario? Is the TLD root management really split up vertically or is the (presumably US-based) TLD parent organization also the final authority for every country TLD? It would be nice to at least have a very high level contingency plan because in worst case I won't be able to google it.

Not sure what the exact concern is here. So far, virtually all countries on Earth are still represented in DNS. Venezuela, Iran, Somalia, etc etc. You can also read a lot of anti-Trump articles and comments on countless web-sites, some under .com and some under other top-domains. As lunatic as Trump is, he hasn’t shut that down. “Is the TLD root management really split up vertically” AFAIK, yes, it is. But if the glo…

That's actually a really good point. Totally missed it.

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

#189

Post by abdullahkhalids »

nine_k wrote: post #152
6thbit wrote: post #123

Earlier quoted context omitted.

Worry not, cause it's not 6 days (144 hours), it is 6-ish days: 160 hours And 160 is the sum of the first 11 primes, as well as the sum of the cubes of the first three primes!

Mr Ramanujan, I presume?

I was hoping Wolfram|Alpha would spit out the above, but on just entering 160 [1], we get

> A regular 160-gon is constructible with straightedge and compass.

> 160 has a representation as a sum of 2 squares: 160 = 4^2 + 12^2

> 160 is an even number.

> 160 has the representation 160 = 2^7 + 32.

> 160 divides 31^2 - 1.

> 160 = aa_15 repeats a single digit in base 15.

[1] https://www.wolframalpha.com/input?i=160

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

#190

Post by mcpherrinm »

hamdingers wrote: post #119
midtake wrote: post #101

Why 6 day and not 8? - 8 is a lucky number and a power of 2 - 8 lets me refresh weekly and have a fixed day of the week to check whether there was some API 429 timeout - 6 is the value of every digit in the number of the beast - I just don't like 6!

It's actually 6 and 2/3rds! I'm trying to figure out a rationale for 160 hours and similarly coming up empty, if anyone knows I'd be interested. 200 would be a nice round number that gets you to 8 1/3 days, so it comes with the benefits of weekly rotation.

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 based on a rough idea that responding to any incident (outage, etc) might take a day or two, so (assuming renewal of certificate or OCSP response midway through lifetime) you need at least 2 days for incident response + another day to resign everything, so your lifetime needs to be at least 6 days, and then the requirement is rounded up to another day (to allow the wiggle, as previously mentioned).

Plus, in general, we don't want to align to things like days or weeks or months, or else you can get "resonant frequency" type problems.

We've always struggled with people doing things like renewing on a cronjob at midnight on the 1st monday of the month, which leads to huge traffic surges. I spend more time than I'd like convincing people to update their cronjobs to run at a randomized time.

Post reply on HN