What is the "real website"? You do not know this in the general case, it is just some rando on the internet, which is indistinguishable from a middle-man.
It is whoever owns the domain. The point is when your client talks to a domain, you know you are actually getting the domain, even if you don't know who owns it or if they're trustworthy.
Not at all. I might have my own DNS server to answer my DNS request or I may trust a specific DNS server (not controlled by my ISP). My DNS entry may be 100% correct and resolving to my actual bank website. But with TOFU, on first use, it is still possible for a router/ISP/middle-man in between to intercept the response being served from the real website and serve a MITM certificate to me.
Why do you say I should consider the middle-man answering the request to be the real website?
If I want to visit chase.com, I want to consider a server controlled by Chase (the company) to be the real website. PKI with a CA that attests the legal entity behind the website guarantees this. I agree with you that Let's Encrypt does not guarantee this. Is your comment scoped to Let's Encrypt only? If so, I agree.
But if we're talking about PKI in general, it seems like a terrible compromise to me to consider a middle-man to be the real website.
I guess we both disagree on a very fundamental point. To me it seems ridiculous to accept that it is reasonable to consider to the middle-man to be the real website. But to you it apparently makes sense. I am unable to understand why though.
> 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.
