It might be time that we discussed what we are getting out of relying on
WHOIS for this information with the improvements we've had into other forms
of DCV. This recent attack has highlighted two things for me:

   1. It's probably time to pull the plug on relying on WHOIS information
   for DCV.
   2. For CAs that don't have publicly accessible endpoints for doing
   domain validation (practically every CA except a handful), it might be
   useful to expose an endpoint that goes through the full DCV cycle and signs
   with a non-trusted key.

For #2, it's important for security researchers to be able to test DCV
logic for CAs that get granted the ability to issue publicly trusted
certificates. Essentially this endpoint would allow the public, and the
root programs to regularly audit any CA's DCV.

It is my opinion that this requirement should be added for new
organizations wanting to be a CA. Existing CAs should be required to
implement this by some future date.

On Wed, Sep 11, 2024 at 9:53 AM Claves Nostrum <[email protected]>
wrote:

> I believe this will be a wider issue since in previous discussions it was
> referenced that CA's typically use tools / ports like linux whois, which
> also has a wrong reference for e.g. .mobi in its TLD config file:
>
> IANA says the whois server for whois.nic.mobi (
> https://www.iana.org/domains/root/db/mobi.html)
>
> whois cmd util uses whois.afilias.net as the whois server for .mobi (
> https://github.com/rfc1036/whois/blob/dc588f10ee8135e17b3a1b6934583476bcb67bed/tld_serv_list#L64
> )
>
> Although whois.afilias.net has the same DNS A records as whois.nic.mobi
> it cannot be presumed it stays that way as the TLD operator might remove /
> decommission the unofficial one and then we might have another example of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
>
> I believe any CA that does not, as Tyrel references, "ensure that updates
> to, e.g., the IANA list, are propagated to production systems" might be
> affected by the same vulnerability.
>
> Op woensdag 11 september 2024 om 21:48:54 UTC+9 schreef Tyrel:
>
>> Folks,
>>
>> I'm sure some of you have already seen this writeup:
>>
>>
>> https://labs.watchtowr.com/we-spent-20-to-achieve-rce-and-accidentally-became-the-admins-of-mobi/
>>
>> The authors claim that several certificate authorities, for at least one
>> TLD (.mobi), query WHOIS servers that are no longer authoritative for a
>> TLD, and in fact by registering the old WHOIS server name to themselves,
>> they were able to provide any information they wanted about domain
>> contacts, e.g. substituting their own email address for validation method
>> 3.2.2.4.2 for any (.mobi) domain. They also mention that they observed some
>> clients (not necessarily CAs) querying the out of date WHOIS location for
>> domains like "google.com".
>>
>> The one CA called out by name in the report has opened a bug:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1917896
>>
>> But my question for other CAs is: from where do you source information on
>> authoritative WHOIS servers for TLDs? What processes do you have in place
>> to ensure that updates to, e.g., the IANA list, are propagated to
>> production systems?
>>
>> My question to the community: given the apparent fragility of WHOIS for
>> obtaining registrant info, should the BRs be updated to only allow, e.g.,
>> direct information from RDAP from the registrar in charge of a given TLD?
>>
>>
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups "
> [email protected]" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/72b25d8e-ab8a-4244-8b53-8422759e0b4fn%40mozilla.org
> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/72b25d8e-ab8a-4244-8b53-8422759e0b4fn%40mozilla.org?utm_medium=email&utm_source=footer>
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAOG%3DJUJZdS9dfecUEUYRvQmv1JOF8iOAf27AOS9QbNp6mKDfOQ%40mail.gmail.com.

Reply via email to