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

A Year-End Letter from our Executive Director

letsencrypt.org

Post reply on HN
Print view View original

101–110 of 155 posts

Re: A Year-End Letter from our Executive Director

#101

Post by bawolff »

candiddevmike wrote: post #94
tptacek wrote: post #82

Earlier quoted context omitted.

There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionatel…

All of the problems you listed around trusting TLDs applies to Let's Encrypt/ACME DNS-01 validation though...

I mean, with dns validation you at least have records that someone did the attack bia cert transparency, with dane the attack is harder to detect.

Re: A Year-End Letter from our Executive Director

#102

Post by phasmantistes »

ggm wrote: post #93

Can somebody from LE explain why "Rust in the kernel" is a story for LE, rather than for Linux itself? Did LE e.g. do the coding? or help? is this a cross-product activity? LE is a system for bootstrapping CA certification, Rust in the kernel is a generalized memory/systems security & safety coding activity. Not that it isn't good, but "why talk about it in a letsencrypt end of year message" -is this the wider "we" a…

It's because it's not just a Let's Encrypt end-of-year message: it's an ISRG (Internet Security Research Group) end-of-year message. ISRG runs multiple projects, including both Let's Encrypt and Prossimo. Prossimo is all about using memory-safe languages to replace critical memory-unsafe code, and Prossimo funded a significant chunk of the work to get Rust into the Linux kernel.

Re: A Year-End Letter from our Executive Director

#103

Post by jiggawatts »

vbezhenar wrote: post #28
jiggawatts wrote: post #9

Earlier quoted context omitted.

> some shady websites What are you talking about? A clever design aspect of Let’s Encrypt is the deliberately short expiry. That forces administrators to automate the issuance and renewal process. Not to mention that you’re not supposed to “download” the private key! The whole idea of PKI is to generate the private key locally and then have a CA sign only the public part. If you’re doing anything else you’ve undermin…

I know better what am I supposed to do. Type "download letsencrypt certificate online" in the Google and you'll find out what I'm talking about. You can think of forcing administrators all the day while Internet is full of expired letsencrypt websites that I regularly stumble upon. The world does not work like that. Letsencrypt should serve its users, not force them onto anything. If I think that I should generate ke…

> Letsencrypt should serve its users, not force them onto anything.

The only way they can serve users is by forcing them to do the right thing.

You're insisting on doing the wrong thing and shouting at the people that are telling you how to do it right.

An analogy would be the equivalent of "not your wallet, not your crypto". Literally millions of naive crypto enthusiasts have just had $9B stolen from them by FTX because they didn't grasp this basic concept. They just wanted something convenient.

With something like PKI or cryptocoins, there are no shortcuts to security.

It's like sticky-taping your key to your locked front door.

Or writing your pin code on your credit card.

Or setting your password to "12345".

Re: A Year-End Letter from our Executive Director

#105

Post by comex »

rainsford wrote: post #71
iuafhiuah wrote: post #43

I am glad it looks like the IETF ACME specification only addresses the HTTP-01 challenge. I really would like to see improvements made to the DNS-01 challenge before it's ratified, namely, let us publish a public key to a TXT record and use the private key to sign the renewal request. Then I can revoke certbot's access to my DNS records and stop hacking the `.well-known` path.

I'll admit I haven't spent a ton of time thinking through all the implications, but that proposal seems like it comes with some significant security tradeoffs. In particular, you'd lose the ability to prove you control the domain name at the time of certificate renewal. Instead, the key pair approach shows you controlled the DNS records for the domain at some point and your entry has yet to be deleted. From the certi…

To be fair, “you controlled the DNS records for the domain at some point and your entry has yet to be deleted” could also describe the HTTP-01 challenge. Admittedly, having the A/AAAA record point to the wrong place is much more likely to be noticed than having a stray TXT record lying around. Perhaps more worrying is the possibility of having a keypair that is legitimately being used to sign certificate requests, but which an attacker also stole a copy of at some point. (Assume that the server owner doesn’t know they were compromised and hence didn’t rotate the key, but the attacker subsequently lost access for some reason.) Such an attacker would likely have also stolen the TLS private key, but that only stays valid for 90 days, whereas for this keypair approach to be useful, the keypair would have to stay valid for a long time or indefinitely…

Re: A Year-End Letter from our Executive Director

#106

Post by jjulius »

ipaddr wrote: post #64
jjulius wrote: post #25

Earlier quoted context omitted.

Sorry, we're giving an ML engineer grief for not knowing much about SSL? Should we tease dentists for not knowing how to grow oranges, too?

Not for not knowing but for being proud that they don't have to.

That's the entire point of LetsEncrypt; assist people who know they need an SSL cert, but don't know much about SSL.

Re: A Year-End Letter from our Executive Director

#107

Post by [deleted] »

candiddevmike wrote: post #94
tptacek wrote: post #82

Earlier quoted context omitted.

There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionatel…

All of the problems you listed around trusting TLDs applies to Let's Encrypt/ACME DNS-01 validation though...

[deleted]

Re: A Year-End Letter from our Executive Director

#108

Post by jjulius »

ipaddr wrote: post #80
TillE wrote: post #63

Earlier quoted context omitted.

Right obviously very few people will be deep experts on the nitty gritty details of any particular thing, but it's weird to work with computers and not have a broad high-level understanding of something as crucial as TLS and PKI.

Not understanding something is to be expected but being proud you don't have to goes against the core of what a programmer is.. curious.

"I don't care to" != "I'm proud I haven't"

You don't know why they haven't taken the time to learn. At least they know enough to know they need an SSL cert. Should I not buckle up in a car if I don't understand the mechanics of how the buckle snaps together?

I don't understand why you're harping on this person for this.

Re: A Year-End Letter from our Executive Director

#109

Post by bombcar »

NavinF wrote: post #49
bombcar wrote: post #48

Earlier quoted context omitted.

Nobody offers more than a year now. It’s annoying. So many old devices still need to be supported and can’t automatically update.

If these devices have internet access they can auto renew. If they don't, they don't need a cert signed by a public CA.

Is there a certbot client for ESXi?

Re: A Year-End Letter from our Executive Director

#110

Post by acdha »

candiddevmike wrote: post #94
tptacek wrote: post #82

Earlier quoted context omitted.

There are a lot of reasons. The real reason DANE isn't deployed is that DNSSEC isn't deployed, and DNSSEC isn't deployed because (1) it's not an operational security win for most companies, and (2) it has an earned reputation for causing nightmare outages. That's why nothing uses DANE: because there are no DANE records to look up, and the most important (high-traffic, whatever) sites on the Internet disproportionatel…

All of the problems you listed around trusting TLDs applies to Let's Encrypt/ACME DNS-01 validation though...

There's one useful exception: say that the Libyan government decided to override bit.ly's DNSSEC records — if all you use is DANE, they've won and they can do that seamlessly for a subset of clients without anyone else noticing. If they try the same thing attacking a DNS-validated certificate system, they lose the covert aspect because Certificate Transparency forces the malicious certificate to be logged in an immutable record.

There are services which monitor those logs to alert owners and it makes it easier for researchers to piece together what happened retroactively, as we saw recently with the TrustCor affair where CT logs were useful for determining what certificates that CA had been issuing.

Post reply on HN