3 ms·

> (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?

by pilif 8y ago

crankylinuxuser 8y ago
No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.
- pilif 8y ago
  > No cert chain for starters. why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?
  - crankylinuxuser 8y ago
    Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.
    - nybble41 8y ago
      If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented. Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.

3 ms·

> (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?

by pilif 8y ago

> (which isn't actually true) how would I discern your self-signed certificate from the one served by the person arp-spoofing the gateway in a Starbucks?

crankylinuxuser 8y ago
No cert chain for starters. The better answer here is some sort of "self signed standard data" for non-CA certs. But right now, testing in a NAT using HTTP2 is a ugly nonstarter.
- pilif 8y ago
  > No cert chain for starters. why would the person who arp-spoofs the gateway in the Starbucks not be able to fetch your self-signed cert chain and mint their own matching chain with the exact same metadata (but of course differing keys)?
  - crankylinuxuser 8y ago
    Then what's your proposal for NATted, self-contained (no gateway), and Tor Onion networks? Sure, if I have a public IP and DNS records pointing towards it, I'm served by LE or a multitude other vendors. But that's a small number of machines on any network.
    - nybble41 8y ago
      If you have a public DNS entry then you can get a certificate from Let's Encrypt using the DNS verification method, even if the name points to a private IP address. DANE would also be an option if it (and DNSSEC) were more widely implemented. Local name resolution (mDNS) could take a page from what Tor already does and encode the public key fingerprint into the domain name. If the key uniquely matches the domain (perhaps just the first part, e.g. b32-key-hash.friendly-name.local) then you automatically get the equivalent of domain validation. While, by itself, this doesn't prove that you're connected to the right domain, by bookmarking the page and visiting it only through that bookmark you would get the equivalent of trust-on-first-use. Browsers would just need to recognize this form of domain name and validate the key against the embedded hash instead of an external CA.