Hacker News Reader

Comment by mlissner | Hacker News Reader

That doesn't actually create a properly encrypted connection. It only encrypts between the user and the site (at CloudFlare), not between the site and Github. Without that last hop being encrypted, you have to weigh whether this is an improvement or not.

View on HN

It significantly decreases the attack surface, since most of the connection will be encrypted inside CloudFare's network or over HTTPs. Should be a clear win for most cases.

You can now actually use CloudFlare to issue a custom certificate for your origin server that it will accept (CloudFlare Origin CA), but of course GitHub pages won't support installing it.

Yes it does - this is all a setting you can choose and since Github does support HTTPS (and has for a while) you can always set it on "strict" and ensure a continuous encrypted connection on both sides of CloudFlare.

But what certificate will Github present for your custom domain? I don't think you can tell CF to accept Github pages's cert for your own domain. They either use their own CA or don't do auth, right? At least on non-enterprise plans.

CloudFlare is what serves your custom domain.

On the backend you point CloudFlare to https://username.github.io and CF will receive the wildcard certificate for *.github.io

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.

https://www.benburwell.com/posts/configuring-cloudflare-univ...

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.

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.

That doesn't work with Github because the cert doesn't match the custom domain.

Reply on news.ycombinator.com