3 ms·

> Simply using TOFU-certificates (Trust On First Use) would achieve this. As a user how would I know if I should trust the website's public key on first use?

octoberfranklin 1y ago
The same way you know if you should trust the WebPKI Rube-Goldberg-contraption: you don't. It's a counterexample, not a recommendation. If you need this guarantee, use self-certifying hostnames like Tor *.onion sites do, where the URL carries the public key. More examples of this: https://codeberg.org/amjoseph/not-your-keys-not-your-name https://codeberg.org/amjoseph/not-your-keys-not-your-name
- akerl_ 1y ago
  I trust the WebPKI infra quite a bit. Cert validation is publicly logged, CAs that do nefarious things get booted from browser trust stores. I can set which CAs can sign certs for my domains, and monitor if any are issued that I didn't expect.
akerl_ 1y ago
I guess we could organize regional parties where site operators and users meet up and exchange key material. I'm sure that will scale and won't have any problems of its own.
1718627440 1y ago
The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly.
- majewsky 1y ago
  TOFU does not help if the ISP is consistently malicious, and serves me the MITM certificate on first use.
  - 1718627440 1y ago
    In that case the ISP becomes the real website. If this is always consistent, then you are always talking with the same entity. This only matters, when your view of the entity isn't solely determined by the domain name. For example you care when someone impersonates google.com, because you expect it to belong to Alphabet Inc., you perceive impersonating when the entity you are talking to changes. When some domain is always constantly resolved to your ISP, then that domain is owned by the ISP in your network.
    - blenderob 1y ago
      > In that case the ISP becomes the real website. But that's exactly what we're trying to avoid. When I want to visit my bank website, I don't want the ISP to become the real website. I don't understand your comments. Your solution to how I trust the website on first use (TOFU) is to trust whatever public key the middle man (the ISP) serves? If you're okay with that, I guess you don't have a problem. But I'm not okay with that, so TOFU doesn't solve my problem.
      - 1718627440 1y ago
        No, in this case this is not the real website, but it's not because of the ISP, it is because you consider that website "my bank website". That's the real issue here. It's not different than someone registering a (similar) domain name and you thinking that this is owned by the bank. If you were to redesign name and address resolution, to enforce connecting to the real physical world entity, this should happen out-of-band. Well, know that I think of it, I think that's what the GNU Name System is trying to address: https://www.gnunet.org/en/gns.html https://www.gnunet.org/en/gns.html . ----- The question seams to be, what do you consider to be the real website? The one that answers to your request? Then the ISP is the real website. In your example you seem to have preconceptions of who might own the website, but these are outside of the network. TLS from Let's Encrypt only enforces that the entity never changes. There are validation schemes where the physical/legal entity is validated, but this is not the case here.
- blenderob 1y ago
  > The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly. Still doesn't explain how I'll confirm that if the website has not been intercepted by a middle man the first time I visit it.
  - 1718627440 1y ago
    In this case it isn't a middle man, but becomes the real website.
    - blenderob 1y ago
      The very problem here is that I am not ok with middle man becoming the real website. If you are ok with that, you don't have a problem. You can use TOFU. Good for you. But I have a problem with that. So I can't use TOFU.
      - 1718627440 1y ago
        I'm saying that this is not your real problem. Your real problem is that you expect the "real website" to correspond to real world entities. And this can be solved better than the current state.
        blenderob 1y ago
        You mean it can't be solved with Let's Encrypt? Yes, I agree. What about TLS certificates attested by CAs who validate the real world legal entity? Would you agree that this is a solved problem there?
        1718627440 1y ago
        Yes this solves it partially. The thing is that people assume that the green lock correspond to the domain name. It would be completely solved, if the browser would still show the validated company name, like it used to be, and then people would only validate that and the CA also validating that there are no similar names. The latter would essentially mean that there is a global coordination of CAs and that there only one entity on the whole world could have the same name, i.e. we only have one jurisdiction.

octoberfranklin 1y ago

The same way you know if you should trust the WebPKI Rube-Goldberg-contraption: you don't. It's a counterexample, not a recommendation. If you need this guarantee, use self-certifying hostnames like Tor *.onion sites do, where the URL carries the public key. More examples of this: https://codeberg.org/amjoseph/not-your-keys-not-your-name https://codeberg.org/amjoseph/not-your-keys-not-your-name

akerl_ 1y ago
I trust the WebPKI infra quite a bit. Cert validation is publicly logged, CAs that do nefarious things get booted from browser trust stores. I can set which CAs can sign certs for my domains, and monitor if any are issued that I didn't expect.

akerl_ 1y ago

I guess we could organize regional parties where site operators and users meet up and exchange key material. I'm sure that will scale and won't have any problems of its own.

1718627440 1y ago

The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly.

majewsky 1y ago
TOFU does not help if the ISP is consistently malicious, and serves me the MITM certificate on first use.
- 1718627440 1y ago
  In that case the ISP becomes the real website. If this is always consistent, then you are always talking with the same entity. This only matters, when your view of the entity isn't solely determined by the domain name. For example you care when someone impersonates google.com, because you expect it to belong to Alphabet Inc., you perceive impersonating when the entity you are talking to changes. When some domain is always constantly resolved to your ISP, then that domain is owned by the ISP in your network.
  - blenderob 1y ago
    > In that case the ISP becomes the real website. But that's exactly what we're trying to avoid. When I want to visit my bank website, I don't want the ISP to become the real website. I don't understand your comments. Your solution to how I trust the website on first use (TOFU) is to trust whatever public key the middle man (the ISP) serves? If you're okay with that, I guess you don't have a problem. But I'm not okay with that, so TOFU doesn't solve my problem.
    - 1718627440 1y ago
      No, in this case this is not the real website, but it's not because of the ISP, it is because you consider that website "my bank website". That's the real issue here. It's not different than someone registering a (similar) domain name and you thinking that this is owned by the bank. If you were to redesign name and address resolution, to enforce connecting to the real physical world entity, this should happen out-of-band. Well, know that I think of it, I think that's what the GNU Name System is trying to address: https://www.gnunet.org/en/gns.html https://www.gnunet.org/en/gns.html . ----- The question seams to be, what do you consider to be the real website? The one that answers to your request? Then the ISP is the real website. In your example you seem to have preconceptions of who might own the website, but these are outside of the network. TLS from Let's Encrypt only enforces that the entity never changes. There are validation schemes where the physical/legal entity is validated, but this is not the case here.
blenderob 1y ago
> The same way I know which real person is serving me the website. I don't I merely know that the owner doesn't change randomly. Still doesn't explain how I'll confirm that if the website has not been intercepted by a middle man the first time I visit it.
- 1718627440 1y ago
  In this case it isn't a middle man, but becomes the real website.
  - blenderob 1y ago
    The very problem here is that I am not ok with middle man becoming the real website. If you are ok with that, you don't have a problem. You can use TOFU. Good for you. But I have a problem with that. So I can't use TOFU.
    - 1718627440 1y ago
      I'm saying that this is not your real problem. Your real problem is that you expect the "real website" to correspond to real world entities. And this can be solved better than the current state.
      - blenderob 1y ago
        You mean it can't be solved with Let's Encrypt? Yes, I agree. What about TLS certificates attested by CAs who validate the real world legal entity? Would you agree that this is a solved problem there?
        1718627440 1y ago
        Yes this solves it partially. The thing is that people assume that the green lock correspond to the domain name. It would be completely solved, if the browser would still show the validated company name, like it used to be, and then people would only validate that and the CA also validating that there are no similar names. The latter would essentially mean that there is a global coordination of CAs and that there only one entity on the whole world could have the same name, i.e. we only have one jurisdiction.