by 1718627440 | 2025-10-15 11:23:30+00:00
I started this thread with this:

> You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man.

What I was talking about is this: I read some URL, maybe on HN. I do not know who sits behind it. The content can be malicious, but whether they were that when the IP packet was assembled, who knows? In fact what is the difference between the "MITM" and "the real one". If "the real one" has never even received my request and the "MITM" doesn't forward it, then the "MITM" isn't a middle man but my connection partner. All the protocols form TCP, DNS to IP and DHCP assume that the connection partner is the one answering.

The contents can be deceptive or something, but this doesn't matter, because things on the internet in general come from people I don't know, should be taken with a grain of salt and don't matter in the real world. I don't care who is the middle man and who not, because both are the same to me.

The only problem here is if you establish credentials with one party and then accidentally send them to another party, e.g. a user/password login. This is solved by TOFU. Note, that this issue is symmetric. I neither want to send data from "the real one" to the "MITM", but I also don't want credentials established with the "MITM" to be received by "the real one", because this is the third-party in this case.

Consider Chase (the company) to provide food delivery. I visit the MITM's site, pay money to the MITM, the MITM serves me food. Where is the problem here outside of trademark issues? This problem only occurs when you have contact with Chase (the company) out-of-band.

What you are talking about is something totally different. You want to be assured that when you "visit" chase.com you are talking with Chase (the company). This is not assured in the general case. Even if there is nothing malicious going on, someone that is not Chase (the company) can be the one answering that. That is on top of issues like goog1e.com.

Yes, this is solved by

- establishing out-of-band that chase.com is Chase (the company) - you inputting the correct string, not some look-a-like - nothing being wrong with address resolution - PKI with a CA that attest the legal entity

Note that you still need out-of-band knowledge.

What Let's Encrypt solves is that browsers don't like self-signed certificates. It would be also solved with self-signed certificates and TOFU.

> Is your comment scoped to Let's Encrypt only?

The article we are discussing this under criticizes Let's Encrypt. However due to the PKI hiding that you still need out-of-band data, we accepted the current state. This is what the article and I criticizes and why the problem isn't only with Let's Encrypt.

In the now deleted comment you wrote:

> Yes, this is one point where I agree with you. But no bank really use Let's Encrypt for certificates. Banks do use certification authority where the legal entity is validated.

This essentially means that Let's Encrypt shouldn't be treated like a trustworthy certificate, which I think I actually would agree. But I wouldn't propose this, because that means we are back to square one before Let's Encrypt, and I couldn't host websites that the common people would visit.

I think this problem can't be solved, before it is accepted that it shouldn't be solved by private companies, but by jurisdictions. It is essentially the age-old identity problem.