Hacker News new | ask | show | jobs
by 0xbadcafebee 421 days ago
That's a much simpler problem to solve than the current one. One attack vector to cover, one set of organizations, one trust list. It's definitely no worse than our current predicament.

Basic math shows how much safer the new model would be:

  - Assume there are 350 CAs, 3 validation methods, and 12 kinds of exploit per validation method (there are more in some combinations but for simplicity I'll say 12).
    (350 x 3 x 12) leaves *12,600* possible attack vectors.

  - Now assume there's 2,650 domain registrars, 1 validation method, and 1 kind of exploit.
    (2650 * 1 * 1) leaves *2,650* possible attack vectors.
So 4.75x fewer possible attack vectors.

Add to this that with only 1 validation method and 1 feature to support, that's way less code, which means much fewer bugs.

Add to that a cryptographic chain of proof that the key of the domain owner was used to sign the request all the way, which we don't have today.
1 comments
cmeacham98 421 days ago
This math only looks good because you're adding an arbitrary unsubstantiated 12x multiplier to the CA numbers.

Of course, neither of us have actual numbers but my gut instinct is that registars are probably about as secure if not less secure than CAs, and there are nearly 10x as many of them.

link
0xbadcafebee 420 days ago
Registrars are less secure because CAs have to follow a strict guideline for security. We could just apply that same standard to the registrars. It would be easier for them to follow since it would be far simpler to use 1 validation method, and using cryptographic verification it's easier to automate validating that it was done successfully.

The 12x multiplier comes from the number of attack vectors to validation methods. The whole system is public knowledge; if you know how each part works, and you know about all the possible security exploits out there, you can just count them.

Here's a brief list off the top of my head, it's not exhaustive:

  - DNS validation. The CA looks up TXT records of a given subdomain.
    Attack 1. DNS cache poisoning
    Attack 2. Compromise the credentials of a DNS admin
    Attack 3. Zero-day exploit in the DNS server
    Attack 4. Zero-day exploit in the DNS web management interface
    Attack 5. Incorrectly configured DNS zone transfer settings.
    Attack 6. BGP spoofing attack on the target DNS nameserver.
    Attack 7. BGP spoofing attack on the CA's DNS resolver.

  - HTTP validation. The CA requests a specific URL over HTTP and verifies the contents.
    Attack 1. MITM the HTTP request/response. (Can be done anywhere across the network, from the CA internal network to the target internal/external network)
    Attack 2-8. Every single DNS attack. You just replace the A/AAAA record when looking up the target HTTP host, with an attacker-controlled http host.
    Attack 9. BGP spoofing attack on the IP of the target HTTP host.
    Attack 10. Zero-day exploit in the target HTTP server.
    Attack 11. Stealing credentials to remotely login to the target HTTP server.

  - Email validation. The CA sends an e-mail to the domain and confirms the reply.
    Attack 1-7. Every DNS attack.
    Attack 8. BGP spoofing attack on the IP of the target MX host.
    Attack 9. MITM the e-mail. This one is extra easy as intermediate unencrypted relays are common/expected.
    Attack 10. Steal the credentials of the mail server admin to remotely log in and intercept/fake emails.
    Attack 11. If it's a site that allows users to register an email address, there are six different email addresses they can try to register; if one works, they can use that to validate certs for that domain.
    Attack 12. Zero-day exploit in the mail server software.
    Attack 13. Zero-day exploit in the mail server's web management interface.
And this is just the run-of-the-mill exploits most experienced hackers can pull off remotely. Haven't gotten into more advanced things like supply-chain attacks, timing attacks, protocol/algorithm flaws, espionage, social engineering, etc.

The big problem is that since validation uses no cryptography whatsoever, all the attacks are fairly trivial. A BGP attack is so easy that it happens by accident on a monthly basis. MITM is easy. Stealing credentials is easy (ask any botnet admin). Attacking DNS is easy (most people don't uses DNSSEC and even if they do their clients/resolvers aren't enforcing validation).

Do an end-run around all this bullshit by asking the people who actually know who owns the domain (the Registrar) to validate it cryptographically.

link