This is where the breakdown is. Cloudflare will get the certificate for *.github.io, however it is making the request for the custom domain. It is unable to validate the certificate.
It is impossible to enable "strict" SSL mode, because it cannot validate the certificate. And as such, a bad if able to trick cloudflare to resolve username.github.io to themselves could use any SSL certificate they choose.
This is admittedly an edge case, but in such an event, the end user would see a trusted certificate and be proxied to a bad site.
You're right - the request to the origin will be encrypted but not fully validated since the host header will be different. It's still an encrypted connection though which is what the OP was asking about.
How do you do that in CloudFlare? I didn't know you could change the host in non-enterprise versions. All I've seen is the ability to proxy request to a specific IP or CNAME.
If you CNAME your site to foo.github.com, it doesn't change the R-URI or Host header.
That article doesn't address what I said at all. That's showing how to disable encryption on the backend (CF to Github) by selecting "Flexible".
Looking at CF's help again and having used them a bit, there seems to be no way at all to enable full encryption (user-CF-github) with CF's non-enterprise offerings. This is because the request from CF to Github is still requested with your domain name (TLS and host header).
In order for it to work with Github's *.github.io cert, Cloudflare would need to offer an option to rewrite the request itself, not just proxy it.
You're right that the host header wouldn't match but Cloudflare has an option to enable SSL to origin without checking for completely validated certificate. They call this Full rather than Strict: https://www.cloudflare.com/a/static/images/ssl/ssl.png
So you can still get an encrypted connection without a verified certificate.
>encrypted connection without a verified certificate
Encryption doesn't work very well without authentication. In most cases any attacker with access to the medium has read+write. And without auth, you only need to, say, change DNS to insert yourself.
Opportunistic encryption is really just a last-line defence against dragnet type surveillance. Which is good, but it's hardly having end-to-end.
It is impossible to enable "strict" SSL mode, because it cannot validate the certificate. And as such, a bad if able to trick cloudflare to resolve username.github.io to themselves could use any SSL certificate they choose.
This is admittedly an edge case, but in such an event, the end user would see a trusted certificate and be proxied to a bad site.