HTTPS for GitHub Pages
github.com
github.com
On the backend you point CloudFlare to https://username.github.io and CF will receive the wildcard certificate for *.github.io
If you CNAME your site to foo.github.com, it doesn't change the R-URI or Host header.
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.
So you can still get an 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.
[1]: https://help.github.com/articles/securing-your-github-pages-...
It's like GitHub pages on steroids and includes free Let's Encrypt based SSL for custom domains, can run builds from your GitHub repo with any static site generator, supports rewrite/redirect rules/proxying/form processing/password protection and much more...
Gotta be cheaper than digital ocean.
I don't think the pricing is too high. If anything, the high end is too low. It's not like they're aiming at personal sites, are they? And for a company, $39 is nothing -- plans should probably start there. (Seriously, who wants to service a customer for $7 a month?)
FWIW I've never seen or heard of Netlify before in my life.
Plus it creates barriers by giving people something to bikeshed over before buying. In fact, I'd wager they're probably better off going to Unlimited on a few more things where they can, and only really focusing on the things that separate high paying customers from smaller ones.
However, one of the features of their highest price ($39/month) plan is that you can use 100 custom domains. If you have 100 domains hosted on Route 53 you will be paying over $50/month for domains, at which point $39/month for the service which actually hosts your static site is entirely negligible. I am curious how many people fall in to that bucket though - it seems more likely that people will run multiple sites with few custom domains, rather than a single site with 100 custom domains.
I am planning to offer some of Netlify's services in a product I am currently building. I'm still working on the pricing model but it is likely to be based on builds per month and bandwidth/storage, rather than the actual number of sites. My cost driver is not 'how many domain names are configured in my HTTP-routing layer', but rather 'how much pressure is each site putting on my build and web servers'.
I don't think people are thinking how nice it is to have someone take care of stuff for you, totally. If there's any sort of issue, one email, and you're done. And people aren't thinking how tiny $39 is.
Again, I've never heard of Netlify before, but the product sounds great. HN is just messed up on pricing because they're looking at AWS costs instead of customer value.
I think HN also devalues their own time: I've been running webservers since the 90s, so I know it's "easy" to do, yet it's one more thing to have to think about. Although I suppose some might enjoy it.
I'd compare this service to CDNs + HTTP Object storage combos like CloudFront+S3. (Still makes this look expensive since those cost cents/GB)
So it's free and doesn't have quota buckets? Checks it out.
This is nothing like GitHub pages… It costs money and has quota buckets
- You CAN force HTTPS for your *.github.io site.
- You CAN use an https://yourname.github.io URL.
- You CANNOT use a custom domain name with a fully secured HTTPS connection.
[1] https://konklone.com/post/github-pages-now-sorta-supports-ht...
Maybe GH doesn't want the responsibility of hosting everyone's private keys.
> HTTPS is not supported for GitHub Pages using custom domains.
Not unsurprising, but unfortunate.
I haven't quite worked out the rules yet but some GH pages allow full TLS on CF (but not strict cert validation obviously) and some require flexible. I think org pages need flexible (plain HTTP) but project ones support HTTPS (if on a subdomain)?
This update may change all that so will need to experiment again. If it does break things then any new sites after the 15th may not be able to be made to work. If using a CF page rule or HSTS headers to permanently redirect to HTTPS then this could be a problem.
https://support.cloudflare.com/hc/en-us/articles/200170416-W...
Do you have any idea how TLS actually works? If this worked out of the box for custom domains, then GitHub would need to be able to impersonate those domains.
At the very least you'd need a way to upload a private key/cert combo that they could server in response to an SNI request. Given the sheer number of sites that they host (every user effectively has a custom GitHub pages page) that's not really feasible though. Hence only support for *.github.io as that only requires a single wildcard cert.
If you redirect your domain to my webserver, I can get a certificate for it. E.g. from Let's Encrypt.
Wordpress.com uses that and offers SSL certificates to "million-plus"[0] blogs with custom domains. It's certainly doable at scale, although I totally understand it not having priority for GitHub (esp if it doesn't fit their current technical setup).
[0] https://en.blog.wordpress.com/2016/04/08/https-everywhere-en...
disclaimer: co-founder of Aerobatic
2 sites, 1 domain, 5 deployments in a 24 hour period
something something Amazon US East
[1] https://help.github.com/articles/securing-your-github-pages-...
That's literally what this article is about.
[1] https://support.cloudflare.com/hc/en-us/articles/200170416-W...
So client to Cloudflare is well protected but Cloudflare to Akami is vulnerable to MITM.
(And according to this new news Akami to Github is properly protected now)
CloudFlare appears to support this, but they actually don't. What they disingenuously call "Full SSL" is just "there has to be any SSL certificate, but we don't event check with a CA." It's completely MITM sensitive.
The only level higher than that is "Full SSL (strict)", which immediately requires a cert valid for the request host available on the origin, as you mention.
Ideally, they'd have an option in between: "Fuller SSL" (or just stop lying about their current options). Require a valid SSL certificate on the origin, for the origin, not for the request host. This way Cloudflare would ask Akamai for the *.github.io cert, and the browser would ask CloudFlare for the custom domain cert.
Yay, tears.
I "cheated" the system by having a script that will redirect you to the HTTPS version if you click on anything from the HTTP protocol, which kind of accomplishes forcing the HTTPS encryption, but not really.
Then I've decided to switch to my own domain and just use CloudFlare (+ whitelisting Tor).
Now I'm kind of thinking about switching to GitLab Pages since they pretty much kick the hell out of GitHub Pages in every single way when you compare their features (like, you can use any static site generator and you can roll your own Lets Encrypt SSL certificate on them).
But still, you can do other things like selecting a different code highlighter (which GitHub deprecated recently).
It's a feature they introduced pretty recently (~ a month ago IIRC), but it always kind of worked with CI + some tinkering (I know this because my organization used our own instance of GitLab as our publishing platform before this feature became a thing).
Just be sure to delete your CNAME file, based on a recent Github behavior change.
You have been able to request Pages sites over HTTPS for some time, but we refrained from officially supporting it because the traffic from our CDN to our servers wasn't encrypted until now.