zlacker

[return to "So this guy is now S3. All of S3"]
1. paxys+x4[view] [source] 2023-05-04 19:13:35
>>aendru+(OP)
This is a terrible implementation of domain verification. dns-01 and http-01 are more or less standardized at this point. Use them, and don't roll your own. Reference: https://letsencrypt.org/docs/challenge-types/.
◧◩
2. bob102+S9[view] [source] 2023-05-04 19:37:46
>>paxys+x4
I don't get http-based verification in general. If you want to really prove someone owns a domain, make them change an authoritative DNS record. Everything else feels like it is begging for edge cases to crop up. Why should my social media or SSL certificate vendor care about my web servers?
◧◩◪
3. throwa+Ji[view] [source] 2023-05-04 20:20:45
>>bob102+S9
Both http and dns verification are stupid. Neither of them prove you own the domain.

http verification proves you temporarily control IP space relative to a viewer. dns verification proves you temporarily control name resolution relative to a viewer.

Both are trivially hacked, multiple ways. By the time someone finds out you did it (if they closely monitor CT logs, which nobody does) you've already had hours, days, weeks to run a MITM on any domain you want. The attack only has to work once, on any of 130+ CAs.

The solution is registrar-level proof. Cert request signed by the private key of the domain owner, sent to the registrar to verify, the registrar signs it if its true, it's sent to the CA who can see the registrar signed it. Now you know for a fact the domain owner asked for the cert. The only possible attack is to steal all three of the owner's private key, the registrar's private key, and a CA's private key.

I have been shouting about this for 10 years, none of the industry incumbents care. The internet is run by morons.

◧◩◪◨
4. justin+Qo[view] [source] 2023-05-04 20:53:35
>>throwa+Ji
I can get behind registrar-level proof. And I can see why it won't happen, and it isn't because it's a bad idea.

One problem I see is the extra overhead for the registrars. Now they have one more thing to do: verify (sign) certificate requests. That extra work is probably enough to get registrars to push back against such a system.

The registrar would be assuming some of the functions of a CA. This would make it easier for a single entity be both registrar and CA. That would threaten the business model CAs and thus they'd push back against such a system.

If the CA were responsible for getting the registrar's verification for a certificate request then that'd add extra work for CAs, and thus the CAs would push back against it. If the domain owner was responsible for getting the registrar's verification for a certificate before submitting it to a CA, then the domain owners would be against it.

And this is all assuming that people could agree on a common set of protocols or data formats for this new system.

[go to top]