←back to thread

155 points kxxt | 4 comments | | HN request time: 0.022s | source
Show context
gethly ◴[] No.45083427[source]
Because those ephemeral LE certificates are such a great idea...
replies(6): >>45083455 #>>45083516 #>>45083798 #>>45083991 #>>45084464 #>>45088393 #
shaky-carrousel ◴[] No.45083516[source]
It is, if your objective is to closely centralize the web. If you make https mandatory, via scare tactics, only people with certificates will have websites. If you make ephemeral certificates mandatory by taking advantage of a monopoly, then only big SSL providers who can afford it will survive.

Then, when you have only two or three big SSL providers, it's way easier to shut someone off by denying them a certificate, and see their site vanish in mere weeks.

replies(6): >>45083645 #>>45083750 #>>45083879 #>>45084701 #>>45086962 #>>45090198 #
1. Tepix ◴[] No.45090198[source]
There should be an option to go without a recognized CA by publishing your website TLS certificate details via DNSSEC.

I don‘t see any disadvantages over automatically issued certificates.

replies(1): >>45093273 #
2. tptacek ◴[] No.45093273[source]
(1) It doesn't work reliably, because middleboxes don't pass DNSSEC/TLSA records reliably, so there has to be a downgrade path, so it's strippable.

(2) It's much slower than the TLS WebPKI.

(3) There's no transparency log and never will be, both because it hasn't been designed and because Google and Mozilla basically had to mug the WebPKI CA's in a dark alley to make CT happen.

(4) It requires you to set up DNSSEC, which is so error prone that some of the largest engineering teams in the world have managed to take their sites (and also countries) offline.

The thing about DNSSEC is that once you turn it on, it's a king-hell pain in the ass to turn it off without incurring an outage. DNS providers know this, and they know ops teams are terrified of DNSSEC, so they push it as a kind of account lock-in tool. There's a reason that the overwhelming majority of large site don't use it.

replies(1): >>45166878 #
3. Tepix ◴[] No.45166878[source]

    > (1) It doesn't work reliably, because middleboxes don't pass DNSSEC/TLSA records reliably, so there has to be a downgrade path, so it's strippable.
They need to be fixed but yes it is a real problem from what i've heard.

    > (2) It's much slower than the TLS WebPKI.
Caching should make it fast enough. Do you have real-world numbers?

    > (3) There's no transparency log and never will be, both because it hasn't been designed and because Google and Mozilla basically had to mug the WebPKI CA's in a dark alley to make CT happen.
That is an excellent point. Do you have a solution?

    > (4) It requires you to set up DNSSEC, which is so error prone that some of the largest engineering teams in the world have managed to take their sites (and also countries) offline.
I really don't like DNSSEC myself – i'd rather have seen DNSCurve https://dnscurve.org/ succeed – but at a certain point, i think we just have to go with it.
replies(1): >>45168497 #
4. tptacek ◴[] No.45168497{3}[source]
It's not going to be fixed. You have to design protocols for the Internet we actually have, not the one you want. I don't have a solution for any of these problems; the conclusion I come to is, DNSSEC is a dead letter. That's happened with lots of protocols in the past, and it is going to happen with this one too.