GitLab Pages Security Issue Notification

This relates into the problem first highlighted for Let's Encrypt's tls-sni-01 (and tls-sni-02 but that never entered production use) validation methods, which cascaded into the entire method 10 of the Ten Blessed Methods.

To recap that: Several popular CDNs or bulk virtual hosts let you type in any hostname and say you're going to host it with them. They figured that if the people who really own that name don't agree, they just wouldn't point their DNS records to the relevant servers and so it's fine. Let's Encrypt's tls-sni family of validations do a DNS lookup for the name to be validated, but then request SNI for a different invalid hostname as a signal. If a CDN or bulk host used for say, example.com allowed another customer on their service to say they wanted the invalid hostname as their "real" name, they could pass the tls-sni validation for example.com and get a certificate issued.

Naively we often assume that it's OK to let users pick names in a service without taking any step to validate that the person asking is entitled to the name. We may even kid ourselves that the custom name doesn't implicitly convey any legitimacy, that @MileyCyrus might be just some 14 year old from Swansea named Miley Cyrus, that mcdonalds.com could be a family web site of the McDonald clan, or that security@gmail.com could just be some bloke who works the doors at a local nightclub. But the reality is that users think names convey meaning even if you specifically tell them otherwise.

GitLab won't be the first to get bitten by this, and they won't be the last.

I have a website hosted there, and manually renew a let's encrypt cert for custom domain pointing to it every few months. Unfortunately this involves removing and re-adding the custom domain.

I got a notification the cert was going to expire soon so I went through my usual renewal process, only to get redirected to the linked post from the new domain button immediately after deleting the custom domain. So the custom domain now 404s which is the last thing I would have wanted.

I'd strongly suggest a warning get attached to the delete domain custom domain button, or something similar, until this is fixed.

IMO, this is user error. GitLab adding validation on their side at app level is a nice to have feature for sure. Ultimately though, keep your DNS records up to date! If you stop using a service, stop pointing your records to it, simple. If you point any record to a service that matches based on CNAME, A or some other arbitrary value expect squatting/"hijacking" to occur if you delete your reservation of that name.

There are so many services with domain ownership validation issues. It's honestly an extremely hairy problem.

Handling all the edge cases is extremely challenging to do so with good UX

When a customer validates ownership do they keep it forever? How long? Do you rescan for txt records? How often? Do you handle customers leaving gracefully? How do you handle new customers re-setting up their domain on a new account?

It's a big mess and it's a lot better to do what cloudfront does and give customers a unique name to CNAME to

As a customer of Gitlab who uses custom domains, I haven't got any email notification about this. Especially when the post says it requires user action. As much as I love gitlab, this negligence is unacceptable.

Correct me if I am wrong. But doesn’t Github Page have the same issue? Both of them fail to validate the ownership of the custom domain.

I examined a whole load of DNS Records (automatically) to check for this problem under DigitalOcean and Vultr a couple of months ago, but for "stray" name-servers rather than poorly assigned A records. There are more vulnerable domains than you might think.