Remix clone Hacker News

And remember kids: there's hundreds of CAs, they all implement validation independently, and you just need one to do one of the three validation methods wrong to make any cert you want. And there's two dozen different attacks that work aside from bugs in validation. Cert validation is swiss cheese.

But there's a fix: have the registrars confirm authority to issue certs using a public key uploaded by the domain owner. The CSR contains a request signed by the same domain owner key. The CA sends the CSR to the registrar, the registrar verifies it was signed by the same key they have, then they send back a newly signed object (that the eventual-https-end-user can later confirm was signed by the registrar, so everybody knows that every step of the way was confirmed cryptographically). This ensures a single secure authorization by the actual domain owner, verified by the registrar of the domain. All you have to change is how the CA validates, and the registrar needs to handle an extra step or two. Solves 95% of the vulnerabilities.

....but nobody's going to do that, because the fact that Web PKI is swiss cheese hasn't threatened a big enough business yet. Once money or politics is threatened, they'll fix it.

▲ peanut-walrus 3 days ago | parent | next [-]

CAA account binding is basically this. Not cryptographically verified but similar idea that the CA confirms you possess a secret (account) before issuing. https://www.rfc-editor.org/rfc/rfc8657

	▲	0xbadcafebee 2 days ago \| parent [-]
		Nope, it's not the same. The point of having the Registrar involved is to side-step the problem of validating a cert request is allowed to request the cert. All the CA validation methods are supposed to be verifying your authorization to request a cert, but they don't do that. They instead verify your authorization to control DNS records, or IP space, or an e-mail address. And there's dozens of exploits to compromise each of those. And they can be chained. And they can be CA-specific. That's not domain authorization, and each of those verification methods lacks cryptographic authentication. Only the Registrar controls the domain, so that is the only way to know that the request is genuinely authorized. We're playing a game of telephone, it's not secure, and it's unnecessary. Just get the registrar involved.

▲ cmeacham98 3 days ago | parent | prev [-]

With your solution, we end up with the same problem just one layer down. Browsers have to contain a list of 'trusted' registars, and an attacker only needs to find one buggy registrar that will incorrectly sign for a domain the attacker doesn't own.

▲ 0xbadcafebee 2 days ago | parent [-]

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.

▲ cmeacham98 2 days ago | parent [-]

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.

▲ 0xbadcafebee a day ago | parent [-]

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.