3 ms·

Surely it could be a lot easier... Everyone already has a known public third party authority -- their domain registrar. Surely the browsers could come up with

Surely it could be a lot easier... Everyone already has a known public third party authority -- their domain registrar. Surely the browsers could come up with some protocol where you generate your own keypair, register the public key with the registrar and keep the private key on the server. Then it could work pretty much like SSH, but with the browser doing out-of-band public key checking. Rather than needing a certificate chain, the browser just checks the server's public key matches the published one. If ok, happy to encrypt. If not, wave flags, and yell "spoof". Verifying the registrar isn't a fly-by-night can be as complicated as needs be, but that way the registrar (who already gets paid to register the domain) does the complex hassle, while the ordinary domain-buyer just has to keep their server's public key up-to-date with the registrar (ie, fill in one web form at the time you register the domain or whenever you change the server key). But alas it is not so at the moment. Instead, the current process puts hassle onto millions of individual domain-owners, while keeping life easy for the few (paid) certifying authorities. And then we wonder why so few people want to do it.

kuschku 11y ago
Even better. Put the public key in DNS, auth the DNS.
- colanderman 11y ago
  This exists: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... It gets some pushback from notable security experts (e.g. tptacek here) because the DNS system (notably the root) is largely state-owned, while registrars are largely privatized.
- wbillingsley 11y ago
  I thought about that, but there's so many DNS caches out there with potential bugs to make them insecure and poisonable. But a set of public keys from the registrar is "content". It's small, so they could just have a server or two to handle it. (But if load/latency was an issue, well everyone's pretty good at content-distribution networks these days...)
  - kuschku 11y ago
    Well, if someone can manipulate your DNS, you have other issues than your SSL certificate anyway. Ideally, DNS should be signed by your registrar.
icebraining 11y ago
So the browsers need to do a secure request to a server of a registrar for each connection? Even assuming you cache the result, latency has just been shot. And what if those servers are down, or slow, or under DoS attack? And what about EV certs?

kuschku 11y ago

Even better. Put the public key in DNS, auth the DNS.

colanderman 11y ago
This exists: https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions https://en.wikipedia.org/wiki/Domain_Name_System_Security_Ex... It gets some pushback from notable security experts (e.g. tptacek here) because the DNS system (notably the root) is largely state-owned, while registrars are largely privatized.
wbillingsley 11y ago
I thought about that, but there's so many DNS caches out there with potential bugs to make them insecure and poisonable. But a set of public keys from the registrar is "content". It's small, so they could just have a server or two to handle it. (But if load/latency was an issue, well everyone's pretty good at content-distribution networks these days...)
- kuschku 11y ago
  Well, if someone can manipulate your DNS, you have other issues than your SSL certificate anyway. Ideally, DNS should be signed by your registrar.

icebraining 11y ago

So the browsers need to do a secure request to a server of a registrar for each connection? Even assuming you cache the result, latency has just been shot. And what if those servers are down, or slow, or under DoS attack? And what about EV certs?