Security blunders in current implementation of domain ownership verification

[LebedevRI]

Select Topic Area

Bug

Body

Hi all.

There are two separate places where Github verifies that a domain is owned by the organization:

1. For the pupose of just verifying the url as related to the organisation: https://docs.github.com/en/organizations/managing-organization-settings/verifying-or-approving-a-domain-for-your-organization
2. When re-issuing a TLS certificate when using a custom domain used for Pages.

I would argue that both of these these checks are done incorrectly,
and thus introduce security vulnerabilities.

Let's examine the second issue first, the TLS cert check.
It is done by querying the DNS records for the domain,
and requiring that the returned A records point at Github Pages.

This check does not actually make any sense from security standpoint,
because should the domain expire, the new owner
can trivially add the same A records,
and Github would not notice the domain ownership change,
and issue an "invalid" TLS cert. This is not quite MITM, but still.

Now, unfortunately, as far as the domain verification goes,
that feature consists of putting a TXT record
with a name directly derived from org (and repo?) name and no salt,
and thus the secret name is not a secret.
And if you can trivially know the name of the DNS record,
you can trivially look up the secret value.

And this verification is only done at the time of verification,
not in perpetuity.

But even if the check would be re-done periodically,
once the domain expires, the new owner
can trivially add the "secret" key-value TXT records
that were looked up before domain expiry.

I would strongly suggest that the verification TXT record name
should be suffixed with a random, unique, unguessable, suffix.
Then, it will no longer be possible to look up the secret value,
without somehow getting hold of the domain's entire DNS Zone Record,
before domain expires.

There is a third issue with TLS cert issuance:
by requiring the A records to point at Github pages,
it is impossible to put said custom domain behing a CDN proxy,
because the A records would no longer directly point at Github pages.

So the A record check really should be replaced
with a TXT record-based domain ownership check,
which already exists - verifying domain as owned by the organisation.

Roman.

[mecodeatlas]

Hey there, @LebedevRI 👋

Thanks for taking the time to write this up. After reviewing the points raised here, there are a few important clarifications that may help clear up some of the assumptions in the post.

First, organization-level domain verification and GitHub Pages custom domain verification serve different purposes. Organization domain verification is not a security feature and is not used to establish trust or ownership for Pages or TLS issuance.

For GitHub Pages specifically, custom domain verification is a continuous process, not a one-time check. This behavior is documented here: Verifying your custom domain for GitHub Pages.

If a domain expires, DNS stops resolving, which prevents both verification and certificate renewal from continuing. In practice, this means GitHub does detect when a domain is no longer valid or reachable.

Re-adding an old TXT record after a domain changes hands would only recreate DNS proof that the current registrant controls the domain. It does not grant access to the previous repository, content, or account, and does not constitute a security break.

Regarding TLS issuance and CDN usage, GitHub Pages already operates as a global CDN. When you point your domain’s A records to GitHub Pages, your site is served through a global anycast network.

If you want to put a Pages site behind another CDN, there are two options:

• Don’t put the custom domain on Pages. Treat username.github.io as the origin behind your CDN.
• Use a different custom domain for Pages (for example, repo-origin.example.com) and use your root domain on your CDN (for example, example.com). In this setup, GitHub gets a certificate for repo-origin.example.com and serves that on HTTPS, and the root domain is not managed by GitHub.

All CDNs support the origin being hosted on a different IP/domain than what’s presented to users. This is a common setup for users who put Pages sites behind Cloudflare.

Hopefully this helps clarify how these systems are designed to work and why the behaviors described here aren’t considered security vulnerabilities. Thanks again for the detailed write-up.

[tcbyrd]

this statement is false, you can't possibly make that generalization.

I'm of course not saying this is how Let's Encrypt works generally. This is a constraint based on how it works if you want to use GitHub Pages to host your site on a custom domain.

"publishing" ~/.well-known/acme-challenge/, and fetching it from the web?

I apologize if I'm missing it, but I'm not clear which part you consider "heavy-handed" and how your suggestion differs. This is exactly how it works today.

[LebedevRI]

Thank you for taking a look!

this statement is false, you can't possibly make that generalization.

I'm of course not saying this is how Let's Encrypt works generally.

This is a constraint based on how it works if you want to use GitHub Pages to host your site on a custom domain.

Let me reword. The way it has been written in https://github.com/orgs/community/discussions/183089#discussioncomment-15437403, reads as "non-github IP -> github-served .well-known ACME challenge will not be found by LE",
which is not generally true. It is impossible to know that just based on a A/AAAA lookup.

"publishing" ~/.well-known/acme-challenge/, and fetching it from the web?

I apologize if I'm missing it, but I'm not clear which part you consider "heavy-handed" and how your suggestion differs. This is exactly how it works today.

Err, i don't follow. The whole point is that this is exactly how this doesn't work today.
Let me explain. As per previous comment, the reason the IP address check is there,
is to estabilish that at the time of the check, the custom domain will actually be directly served by Github Pages, quote:

So instead of allowing the challenge process to start when we can reasonably be sure it will fail, we ask users to setup the A/CNAME records before we ask Let's Encrypt to perform the check. This is practically more about not putting the domain in a situation where failed attempts to respond to the challenge will trigger Let's Encrypts rate limiters. We used to not require this first, and users would sometimes have to wait hours for a retry once they finally got DNS setup. If the DNS is setup correctly first, the HTTP-01 challenge will likely succeed on the very first attempt and require no retries.

You want to know that should you proceed with HTTP-01 challenge,
and serve ~/.well-known/acme-challenge/<???>, that LE will successfully fetch that file.
You do that by just requiring that the domain resolves to Github Pages, and that is what i'm calling heavy-handed.
(Now, yes, as a safety net, sure, this is better than not having such a check, but it's very restrictive for obvious reasons,
because, as we've disscussed, you can't actually change the Origin Server in every CDN.)

I don't quite understand whats not obvious about the alternative approach?
The problem you want to solve: you want to estabilish for a fact that that the served challenge file will be fetched from Github.
Instead of asking LE for a challenge, and serving it in ~/.well-known/acme-challenge/<???>,
just come up with your own random challenge ~/.well-known/acme-challenge/gh-<???>, serve it there,
wget it from http://<custom-domain>/.well-known/acme-challenge/gh-<???>,
and compare it with what you've expected to be there. If it matches, then LE shouldn't nessesairly fail either.

Let me know if i should try to reword this once more if this is still not understandable...

[LebedevRI]

Let me know if i should try to reword this once more if this is still not understandable...

In other words, currently, before performing LE's HTTP-01 challenge,
you, effectively, perform "a variant of DNS-01 challenge" (= A/AAAA record check).
I'm suggesting that you should instead perform your own HTTP-01 challenge,
as that is less invasive than DNS-01 challenge.

[tcbyrd]

Ah I see what you're saying. It's an interesting thought. There's certainly more things to take into account with that model around how it changes abuse/domain masking patterns. We've had discussions similar to this around making Pages work better for people who want to use it with their own CDN. I can't commit to any changes, but I'll add the discussion to our backlog.

[LebedevRI]

@tcbyrd thank you!