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

10 Years of Let's Encrypt

letsencrypt.org

Post reply on HN
Print view View original

221–230 of 361 posts

Re: 10 Years of Let's Encrypt

#221

Post by morshu9001 »

crapple8430 wrote: post #163
t1234s wrote: post #87

Lets hope they stay independent and never get acquired by Google or any other large tech company. You can imagine a web where SSL issuance is used as a tool to censor websites. I think most browsers have been made to make standard http sites look malicious to normal users.

If Google wants to censor your website, they have a variety of other, more effective methods, like by adding it to their safe browsing blacklist, which is also used in many Firefox installs.

Or even more apples to apples, they could ignore your cert in Chrome

Re: 10 Years of Let's Encrypt

#222

Post by accrual »

jjice wrote: post #5

Let's Encrypt was _huge_ in making it's absurd to not have TLS and now we (I, at least) take it for granted because it's just the baseline for any website I build. Incredible, free service that helped make the web a more secure place. What a wonderful service - thank you to the entire team. The CEO at my last company (2022) refused to use Let's Encrypt because "it looked cheap to customers". That is absurd to me beca…

Seconding the effect of Let's Encrypt on the world of TLS. I remember getting into web applications in the late 2000s and rolling my own certificates/CA and it was a huge, brittle pain. Now it's just another deployment checkbox thanks to LE.

Re: 10 Years of Let's Encrypt

#223

Post by kbolino »

nixpulvis wrote: post #146

Is there a notion of tier 1 and tier 2 certificates? Like if I setup paid and backed by contract agreements with a cert provider, does this give users more confidence that their lock icon in the browser actually means they are talking to who they think they are? It's one thing to provide a cert to provide secure encrypted TLS, it's another thing to establish identity with the user. Though, most users would never noti…

There are Extended Validation (EV) certificates, and for a couple of years browsers gave them special treatment (typically, a green lock indicator instead of gray, sometimes accompanied by the validated business name). However, they were eventually demoted to the same appearance as ordinary Domain Validation (DV) certificates for a couple reasons:

1) This is not as useful as it sounds. Business names are not unique, and the legal entity behind a legitimate business may have a different name that no one has ever heard of.

2) Validation gets dicier as the world gets opened up and as laws and customs change. The higher tier confers greater prestige and legitimacy, but the only discriminator really backing it is money.

Re: 10 Years of Let's Encrypt

#224

Post by bangaladore »

dale-cooper wrote: post #214
invokestatic wrote: post #193

Earlier quoted context omitted.

I have an almost identical story except the state in question was Nevada. I’m curious what “dubious” domain it was, for me it was video game cheats. Maybe I’m actually the co-owner you’re talking about. :)

This made me curious. Like selling cheats for games?

Yes, both in the case of them and I.

Re: 10 Years of Let's Encrypt

#225

Post by duskwuff »

crote wrote: post #171
wbl wrote: post #165

Earlier quoted context omitted.

It was used correctly. What CAs wanted to sell wasn't something browsers wanted to support, and EV was the compromise. It just happens that what EV meant wasn't that useful irl.

What's the alternative, showing the company's unique registration ID? CAs invented EVs because the wanted to sell something which could make them more money than DVs. The fact that company names aren't unique means that the whole concept was fundamentally flawed from the start: there is no identifier which is both human-readable and guaranteed to uniquely identify an entity. They wanted to sell something which can't…

The alternative would have been to have the CA use human judgement when approving EV certificates and reject applications from organizations whose names shadowed better-known firms, or to only accept applications from a select set of organizations (like, say, banks). But either of those possibilities would have increased the cost of the program and limited the pool of applicants, so CAs chose the cheap, easy path which led to EV certificates becoming meaningless.

Re: 10 Years of Let's Encrypt

#226

Post by ekr____ »

cyberax wrote: post #204
tptacek wrote: post #195

Earlier quoted context omitted.

DANE isn't going to happen, and if you want to tilt at that windmill, it's Chrome and Mozilla you need to pressure, not LetsEncrypt.

I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time. Long shot? Yes. But not impossible.

What's the incentive for individual sites or browsers to do this?

From the site's perspective, they're going to need to have a WebPKI certificate for the foreseeable future, basically until there is no appreciable population of WebPKI-only clients, which is years in the future. So DANE is strictly more work.

From the browser's perspective, very few sites actually support DANE, and the current situation is satisfactory, so why go to any additional effort?

In order for technologies to get wide deployment, they usually need to be valuable to individual ecosystem actors at the margin, i.e., they have to get value by deploying them today. Even stipulating that an eventual DANE-only system is better, it doesn't provide any benefit in the near term, so it's very hard to get deployment.

Re: 10 Years of Let's Encrypt

#227

Post by kbolino »

tptacek wrote: post #207
cyberax wrote: post #204

Earlier quoted context omitted.

I mean, these are the steps that can bring it. And with Let's Encrypt as a safe fallback, it actually is feasible this time. Long shot? Yes. But not impossible.

The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)

Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.

Re: 10 Years of Let's Encrypt

#228

Post by tptacek »

kbolino wrote: post #227
tptacek wrote: post #207

Earlier quoted context omitted.

The first step you'd need is a reliable way to deliver DNSSEC records to browsers, which does not currently exist. So I feel like you're missing at least a step 0, if not a step -1 (of getting ~anybody to actually sign zones.)

Aren't browsers generally implementing their own DNS resolution (via DoH) nowadays anyway? Not sure it helps that much, but operating systems not enforcing/delivering DNSSEC seems like a side-stepped problem now.

No, not as a general rule they aren't. And remember, the DNSSEC record delivery problem isn't an issue for the majority of all browser sessions, just a small minority that are on paths that won't pass DNSSEC records reliably. Since you can't just write those paths off, and you can't really reliably detect them, you end up needing a resolution fallback --- at which point you might as well not be using DANE.

This was a big enough issue that there was a whole standards push to staple DNSSEC records to the TLS handshake (which then fell apart).

Re: 10 Years of Let's Encrypt

#229

Post by anonymars »

kbolino wrote: post #208
array_key_first wrote: post #164

Earlier quoted context omitted.

Conflating transport-layer encryption with authenticity is the problem. The former should always be standard, the latter is unrelated and IMO needs a different mechanism.

Absent widespread adoption of DNSSEC, which has just not happened at all , I don't see any alternative. The authentication must be done before the encryption parameters are negotiated, in order to protect against man-in-the-middle attacks. There must be some continuity between the two as well, since the authenticated party (both parties can be authenticated, but only one has to be) must digitally sign its parameters.…

This applies to grandparent too (for the record I largely agree with them) but the issue isn't just "authenticity" but "identification" -- there's no real attestation about who is in on the other end of the site. This identity was once at least somewhat part of the certificate itself.

Re: 10 Years of Let's Encrypt

#230

Post by nixpulvis »

kbolino wrote: post #223
nixpulvis wrote: post #146

Is there a notion of tier 1 and tier 2 certificates? Like if I setup paid and backed by contract agreements with a cert provider, does this give users more confidence that their lock icon in the browser actually means they are talking to who they think they are? It's one thing to provide a cert to provide secure encrypted TLS, it's another thing to establish identity with the user. Though, most users would never noti…

There are Extended Validation (EV) certificates, and for a couple of years browsers gave them special treatment (typically, a green lock indicator instead of gray, sometimes accompanied by the validated business name). However, they were eventually demoted to the same appearance as ordinary Domain Validation (DV) certificates for a couple reasons: 1) This is not as useful as it sounds. Business names are not unique,…

Yea, this was what I thought I'd dealt with before but I couldn't remember.

It's too bad the same hasn't happened to software notarization and signing systems.

People will argue that having payments enforced some accountability, but I'm not really convinced.

Post reply on HN