←back to thread

489 points gslin | 4 comments | | HN request time: 0s | source
Show context
pests ◴[] No.42191619[source]
It feels like just yesterday I was paying for certs, or worst, just running without.

Can't believe its been ten years.

replies(1): >>42191666 #
ozim ◴[] No.42191666[source]
Can’t believe there are still anti TLS weirdos.
replies(7): >>42191688 #>>42191718 #>>42191893 #>>42192714 #>>42192733 #>>42193057 #>>42193614 #
Pannoniae ◴[] No.42191893[source]
TLS is not panacea and it's not universally positive. Here are some arguments against it for balance.

TLS is fairly computationally intensive - sure, not a big deal now because everyone is using superfast devices but try browsing the internet with a Pentium 4 or something. You won't be able to because there is no AES instruction set support accelerating the keyshake so it's hilariously slow.

It also encourages memoryholing old websites which aren't maintained - priceless knowledge is often lost because websites go down because no one is maintaining them. On my hard drive, I have a fair amount of stuff which I'm reasonably confident doesn't exist anywhere on the Internet anymore.... if my drives fail, that knowledge will be lost forever.

It is also a very centralised model - if I want to host a website, why do third parties need to issue a certificate for it just so people can connect to it?

It also discourages naive experimentation - sure, if you know how, you can MitM your own connection but for the not very technical but curious user, that's probably an insurmountable roadblock.

replies(7): >>42191942 #>>42192026 #>>42192088 #>>42192426 #>>42192479 #>>42193243 #>>42203762 #
ratorx ◴[] No.42192026[source]
> if I want to host a website …

The fundamental problem is a question of trust. There’s three ways:

* Well known validation authority (the public TLS model)

* TOFU (the default SSH model)

* Pre-distribute your public keys (the self-signed certificate model)

Are there any alternatives?

If your requirement is that you don’t want to trust a third party, then don’t. You can use self-signed certificates and become your own root of trust. But I think expecting the average user to manually curate their roots of trust is a clearly terrible security UX.

replies(2): >>42192098 #>>42192280 #
1. xorcist ◴[] No.42192280[source]
> Are there any alternatives?

The obvious alternative would be a model where domain validated certificates are issued by the registrar and the registrar only. Certificates should reflect domain ownership as that is the way they are used (mostly).

There is a risk that Let's Encrypt and other "good enough" solutions takes us further from that. There are also many actors with economic interest in the established model, both in the PKI business and consultants where law enforcement are important customers.

replies(1): >>42192322 #
2. ratorx ◴[] No.42192322[source]
How would you validate whether a certificate was signed by a registrar or not?

If the answer is to walk down the DNS tree, then you have basically arrived at DNSSEC/DANE. However I don’t know enough about it to say why it is not more widely used.

replies(2): >>42192474 #>>42200482 #
3. xorcist ◴[] No.42192474[source]
How do you validate any certificate? You'd have to trust the registrar, presumably like you trust any one CA today. The web browsers do a decent job keeping up to date with this and new top domains aren't added on a daily basis anyway.

Utilizing DNS, whois, or a purpose built protocol directly would alleviate the problem altogether but should probably be done by way of an updated TLS specification.

Any realistic migration should probably exist alongside the public CA model for a very long time.

4. tptacek ◴[] No.42200482[source]
A recent thread going into details of why (only a tiny fraction of zones are signed, in North America that count has gone sharply down over recent intervals, and browsers don't support it):

https://news.ycombinator.com/item?id=41916478