[PuffinBlue]

Standard disclaimer: Cloudflare only secures the communication between the visitor and Cloudflare's network, not between Cloudflare and GitHub Pages when using a custom domain and the 'Flexible SSL' feature Cloudflare provides which you are talking about.

So an attacker can still alter/intercept content between GitHub Pages and Cloudflare before it gets to the visitor.

To some, the illusion of security might be considered more harmful that knowing you have none at all.

For an alternative, GitLab Pages offers HTTPS on custom domains, provisioned by LetsEncrypt I believe.

Netlify does something similar.

Both alternatives also allow any build system you configure.

[michaelbrooks]

I would like to know why GitHub doesn't do something similar to Netlify and GitLab. Surely it can't be that hard if some what smaller companies can already implement this?

Also, if using CloudFlare on a static site that collects no form data and only has links to external websites, would it matter so much, or is it just as important to remember about the potential harms?

[PuffinBlue]

I'm not sure why GitHub doesn't offer TLS over custom domains. They may have some limimtation in how the Pages system is built that means reworking it to introduce this function might be prohibitively costly at the moment.

The answer to the second question is "I guess it depends".

In one way I think it's more about perception - https should be https and https should be secure. Not https sort of halfway along the connection, then clear and unsecure for the rest over the public internet.

That's what a lot of people have trouble with over Cloudflare's particular popularisation of this 'broken' https model.

Also, all the data hoovered up by NSA et al puts a picture together, maybe about a person, their habits, what sites and content they read etc etc. Thanks to SNI https will likely leak the domain, but other than that it'll secure the rest of the info.

And what if (like I do on my site) I share a PGP key fingerprint? What if that's midified over the insecure portion of the connection? Now any communication by that route might be compromised.

I get that it can be seen as pedantic, but all steps in the connection as a whole need to be secure if https is to remain trusted.

I suppose overall the push is (and should be) towards default encryption and privacy for the visitor. That's something I'd support at least.