HTTPS for GitHub Pages
github.comDoes anyone know if github is planning to support https for custom domains?
"HTTPS is not supported for GitHub Pages using custom domains"[1] which is annoying.
[1]: https://help.github.com/articles/securing-your-github-pages-...
Custom domains would be huge for me, but I totally understand. How would they ever manage to do it? They'd either need a zillion separate entries, or the broadest wildcard cert ever.
Lots of certificates with 100 hostnames each is how CloudFlare does it.
Let's Encrypt?
Separate entries in what? Computers do pretty good at handling many "entries". TLS will indicate the host so they can send the right cert back.
Sorry, I meant in an Apache config file or something.
Or they could let users specify their own certs.
Wordpress did this by issuing Let's Encrypt certs on demand for every domain people CNAME their way.
I just set up HTTPS in ten minutes using a free cloudflare account and github pages with my custom domain. You do kind of add the middleman of Cloudflare, but I'm totally okay with that.
Check out https://www.netlify.com (disclaimer, I'm a co-founder).
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...
> It's like GitHub pages
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
Your pricing model is extraordinarily expensive.
I consider your pricing to be completely out of touch with reality.
What sort of price would you consider good for static site hosting? GitHub provide theirs for free as it's a loss-leader, where as this is ther main business.
Something not based on made up metrics like domain names. I'm actually using up space, bandwidth and CI time. Charge me on that.
$4 a month (billed monthly) for 5 GB storage.
Gotta be cheaper than digital ocean.
I love my hosting (https://www.scaleway.com/pricing/#pricing_baremetal): 3.6 € for 50 GB and total freedom.
I agree with the others. You can host a dynamic site on digitalocean for half the cost.
DO isn't in the same market as this, at least going off their websites. DO means doing all the work yourself. Netlify handles everything.
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.
You raise an interesting point. The prices seem too high for some commenters. They are presumably capable of doing this themselves on a DO box so they do not think it is valuable enough to justify that price.
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'.
Netlify never misses an opportunity to self-promote in these SSG related threads, but AWS S3/Cloudfront/route53 is so cheap and simple for the audience that would even understand the point of Netlify, it's difficult to understand their target market. Netlify is priced like Squarespace, Wix, Weebly, etc. which are quite a bit simpler.
The fact that I can click on their homepage and drag-n-drop a site folder and have it just work is pretty damn slick. $39 is nothing if you don't have to deal with stuff. The absolute cheapest guys I work with are at least $50/hr. So if it saves an hour here and there it's worth it. And more likely, you'll spend 3-4 figures in time if there's any sort of hiccup in your AWS setup.
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 think they could be much improved by allowing all the features to be modified with sliders and checkboxes with the Free/Advanced/Pro presented as presets.
Does that actually work? I know it's appealing to tech types, but it's confusing to people in general. They probably are better off going unlimited on a few things if they can. People are incredibly weird about usage-based pricing.
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.
They are advertising in a thread about GitHub pages. I'd expect private pages/unpaid open-source projects are the vast majority of users of GitHub pages.
Plus a lot of headaches of maintaining a machine and an OS running on that machine that cost you if you value your time. Static sites + platform = stateless.
I'd compare this service to CDNs + HTTP Object storage combos like CloudFront+S3. (Still makes this look expensive since those cost cents/GB)
I added https for my personal blog using cloudflare
Same. It took me all of ten minutes to do, with a free account. Now, if I were running some service or a huge site, I'd probably want https setup on the server side and not just use Cloudflare as an inbetween. But for a personal blog it does everything I need it to do, with zero hassle.
Not as yet. Check out https://www.aerobatic.com
Currently, they don't have plans. just use cloudflare.
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.
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
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.
That doesn't work with Github because the cert doesn't match the custom domain.
Not until Fastly (Github's CDN) makes it possible.
Fastly does support https so I'm assuming it's a configuration problem.
Frequently changing pk enc key to setup tls connections with different certs can have a performance impact too. Let alone security implications of managing someone else's private keys.
True, but that is a config problem to be fair
So now github "sorta sorta" [1] supports https:
- 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...
Doesn't appear to work with custom domains.
Cloudflare's free plan includes one-click SSL for custom domains. That's what I use for my github pages sites.
Although it doesn't validate the backend certificate.
In some cases it doesn't even connect with TLS due to some connection issue with GitHub / fastly and you need to set it to flexible (no encryption). I wonder if this new forced HTTPS redirect will change/break that?
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.
If that's what you are talking about, you can select "Full (strict)" in the SSL options to enforce origin certificate validation.
https://support.cloudflare.com/hc/en-us/articles/200170416-W...
But this doesn't work because the backend certificate is invalid (it covers *.github.io rather then example.com).
But you'd give cf that cname I think
Last time I tested this cloudflare validated using the domain name, not the cname.
Probably in the works? SNI should make this pretty easy now, right?
Maybe GH doesn't want the responsibility of hosting everyone's private keys.
From the documentation:
> HTTPS is not supported for GitHub Pages using custom domains.
Not unsurprising, but unfortunate.
I'm still using kloudsec for this [1] , they presented themselves on HN sometime last year.
We're working on a static site hosting service called PubStorm (https://www.pubstorm.com) that allows SSL on custom domains. It's free; we're also working on some powerful features that will set it apart from gh-pages.
> Doesn't appear to work with custom domains.
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.
> 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.
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...
I would hope not. If Github could generate valid SSL certs for random domains, something would be very broken.
It would just request LetsEncrypt to generate those certs and then prove the "ownership" (more like "control") of those domains by whatever method LetsEncrypt wants (.well-known perhaps?).
Yup, .well-known should be pretty simple for them to implement.
For those on Bitbucket, <username>.bitbucket.io is the HTTPS equivalent of <username>.bitbucket.org.
ICYI, you can also get free, self-renewing, wildcard SSL certs for custom domains on Bitbucket by using the Aerobatic add-on for Bitbucket. [https://www.aerobatic.com]
disclaimer: co-founder of Aerobatic
Great service! For those wondering what are the limitations of the otherwise very generous free plan:
2 sites, 1 domain, 5 deployments in a 24 hour period
something something Amazon US East
I just noticed it this morning when trying to put up a demo file for a project. I was confused by the docs saying 'don't do anything sensitive because no HTTPS', but clearly seeing the https:// URLs.
Thank you GitHub for this gift, static web sites and now forced https
Forced? You can enable and disable it in every repo's settings.
Not for "GitHub Pages sites created after June 15, 2016 and using a github.io domain."[1]
[1] https://help.github.com/articles/securing-your-github-pages-...
What's the best way to get HTTPS for custom domains? Letsencrypt or Cloudflare? I don't think those are encrypted end to end, no?
Cloudflare wouldn't be e2e in the sense that the SSL would terminate at Cloudflare, which would then open a new SSL connection to GitHub. Everything would be properly encrypted, but Cloudflare would indeed have access to the plaintext (i.e. it isn't e2e).
This isn't necessarily true. For example when you want to direct example.com to example.github.io Akami (serving for Github) will serve the certificate for *.github.io. Because this certificate is obviously invalid for the request you have to disable certificate validation in Cloudflare.
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)
You're right. And it's a shame, because they're so close.
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.
Let's Encrypt is a certificate authority and provides certificates and so it would be end-to-end. However, CloudFlare is not end-to-end unless the server already supports HTTPS.
I wouldn't call CloudFlare end-to-end encrypted. They see the plaintext, independent of whether communication with the backend is encrypted or not.
CloudFlare has a detailed explanation of the various options[1].
[1] https://support.cloudflare.com/hc/en-us/articles/200170416-W...
> CloudFlare is not end-to-end unless the server already supports HTTPS.
That's literally what this article is about.
HTTPS isn't supported if you're using GH Pages with a custom domain.
Not for GitHub, but GitLab does support HTTPS for custom domains by letting you upload your own SSL keypair. I use mine with Let's Encrypt.
Nice work GitHub! That's huge! I think that means you could now use GitHub pages for Slack services that required HTTPS? If so, that's really awesome!
About damn time!
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).
I’m not familiar with GitLab Pages but you can already use any static site generator with GitHub Pages as well.
Huh, turns out you're right. Not sure if that was the case when I started moving to GitHub (~15 months ago) or not, but looks like it's a thing now.
But still, you can do other things like selecting a different code highlighter (which GitHub deprecated recently).
It's always been the case. Github Pages has always been just a static file host.
To clarify, you mean you can if you add the output to your git repo right? Currently I have gh pages set to automatically build my site with jekyll, but I believe they limit plugins to only safe ones.
Are you sure that's not a Gitlab EE-only feature?
Yes, I am: https://pages.gitlab.io/
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).
Yes, it's a GitLab EE-only feature, but it's also available for free on GitLab.com, which is running GitLab EE.
I've been running the HTTPS Everywhere add-on and hadn't realised that this wasn't already a thing. As the post says, they have supported HTTPS for a while and this is just adding a redirection option so you don't need to resort to JS hacks. It doesn't say if they are using 301 redirects or HSTS headers, I'm guessing the former.
You can enable HTTPS for custom domains using this approach: https://blog.jeaye.com/2016/03/01/github-pages-https/
Just be sure to delete your CNAME file, based on a recent Github behavior change.
From the announcement (because I was confused):
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.
Sweet. Was just lamenting its absence.
If I understand it correctly, the same HTTPS certificate is used for all GitHub pages websites. So hypothetically, I could do a MITM attack and redirect a user from an HTTPS protected GitHub pages site to my malicious GitHub Pages site right? (although the url would be different... but could be similar)
You don't have access to their private key. The fact that it is the same certificate is irrelevant. Anything you can do now, you could also do if they'd use separate certificates per subdomain.
Ya, I guess it's not a big deal.