Add HTTPS support to Github Pages including custom domains

[konklone]

NOTE to anyone stumbling on this thread - there are many people subscribed, so please do not comment here unless you have something new to add that is not already discussed above in this long, detailed (and I hope helpful!) discussion thread.

---

Update: GitHub *[announced official support of HTTPS for .github.io domains](https://github.com/blog/2186-https-for-github-pages), which is awesome**, and a clear first step. They clearly intend to move GitHub Pages in a secure direction, and this will help GitHub find and fix bugs as they (hopefully) figure out how to do custom domains.

However, this issue is not resolved yet, as custom domain support is a core issue affecting thousands of websites, including the homepages of many prominent software projects (not to mention GitHub's own conference, CodeConf). GitHub Pages doesn't offer complete HTTPS support until custom domains are supported.

To enable HTTPS for your *.github.io subdomain, flip the switch in your settings as described in GitHub's official documentation. 🎉

---

Github obviously takes HTTPS very seriously. It was early to switch to HTTPS everywhere in the site, and @dbussink has already made some great strides in shoring it up for Github.

Recently, Github has given Pages a proper home and place in the Github suite of offerings. I was extremely happy to see that, because Github Pages is one of my favorite things on the Internet and has amazing potential. It's being used for more than simple project pages, and that's only going to continue as Github's reach and accessibility improves.

Given all that, Github should figure out how to support HTTPS on Pages. Encryption is becoming the standard for the entire web, for many obvious reasons -- to the point that Chrome and Firefox will require HTTP 2.0 requests to be encrypted.

This is an issue I've brought up with @benbalter from Github before, on a few occasions. We talked about it a bit last month on Twitter, and he raised the dual point that most people wouldn't turn on HTTPS, yet turning it on by default would wreck a lot of unsuspecting people's sites with mixed content warnings.

These are good points, but this can be addressed by:

• making HTTPS the default for new Github Pages going forward
• provide an option for existing Pages to opt-in to HTTPS
• provide an option for future Pages to opt-out of HTTPS

In other words: a checkbox, defaulting to on for all future Github Pages.

This is the best of both worlds: no one gets surprised with mixed content warnings, and Github gets to proceed with a strong HTTPS policy that will bring a lot of content into the encrypted Internet (aka the future). People who really have to deal with non-HTTPS content can continue to use Pages by unchecking the box.

So how would this work? Covering *.github.io domains is comparatively straightforward - install a wildcard certificate.

However, if custom domains weren't supported at the same time, this could pose its own problems: I'm unsure how that would impact automatic redirects to custom domains -- it's not considered best practice to redirect from an HTTPS URL to an HTTP one, and I've seen Chrome flag such a redirect as a mixed content warning.

Additionally, it would require potentially confusing language and settings to handle different cases, as people add and remove CNAME files. So, it's probably worth tackling both situations at once.

While there are a few solutions, realistically, I believe this means building a dedicated settings pane for managing private keys and certificates. Certificates would need to be handled at the project level, but private keys could be managed at the user level.

I believe the infrastructure of web hosting can and will rework itself to make encryption on every wire standard and easy for publishers and consumers alike. Github is in a position to really help move that needle, and get huge praise for doing so -- not to mention a competitive edge in site hosting.

This is a non-trivial feature request, but the challenge it poses is why I'm not aware of any major option right now for simple, free, secure web hosting -- and why Github meeting this challenge would be so important. Making it easier for people to do powerful things is what Github is all about.

[konklone]

This ticket is an adapted version of an email I sent Github support on January 23, 2014. I sent another followup on January 27 after hearing no response:

So given today's leak about the NSA and GCHQ using location data from smartphone apps, I wanted to update this thread with some more context, and a real-world example.

We're actually using Github Pages data in our work at the Sunlight Foundation, from the unitedstates/districts project, to serve up GeoJSON files that our popular Congress app for Android directly downloads and renders.

I've already updated our app to use HTTPS for nearly all of its connections, including submission of latitude and longitude to our servers. I've also nudged Mapbox to use HTTPS in its Android SDK, so our downloaded map tiles don't leak information either.

The last remaining issue is the GeoJSON URLs themselves, served from a custom domain, theunitedstates.io, over Github Pages. "Congressional district" is not a very high resolution location indicator, but even still, it is something our app is now leaking to any institution with the capability to scour the Internet's pipes for arbitrary metadata.

After today's leak, I may soon have to move these GeoJSON files outside of Github Pages, to ensure that our app is using HTTPS for everything. We'd like to be able to speak clearly and strongly about how we value user privacy, without having to talk about exceptions.

Thanks for the response, and for taking my request seriously.

On January 29, I got this response:

Hi Eric,

Thank you for the extra information about your specific usage of GitHub Pages. While we understand that HTTPS support might be very important for your specific situation, we cant make any promises whether we will end up adding this feature.

We are constantly aiming to improve all aspects of GitHub and thank you once again for your detailed feedback.

Cheers, [Name removed]

[konklone]

Finally, I've updated the READMEs for two projects I operate on Github Pages that provide permalink-able resources to the public, unitedstates/districts and unitedstates/images, to mention that Github Pages doesn't support HTTPS, and to email Github about it if they think that's problematic.

[captn3m0]

I'd be happy even if the https support was *.github.io only. Building a secure system for all the certificates and hosting them properly would be hard. But heroku handles this pretty well, so can github.

On a sidenote, heroku does piggyback ssl for all the *.herokuapp.com sites by deafult, although I don't know if SSL support was built in from the start, or was flipped on some day (can't find any references to mixed content warnings on herokuapp.com, so it seems it was on from day 1)

[patcon]

:+1:

[waldoj]

:+1:

[konklone]

As @benbalter alluded to on Twitter, Github has now tentatively enabled HTTPS for *.github.io domains!

For example: https://sunlightlabs.github.io/congress/

The configuration is different - here are SSL Labs' reports for github.com and sunlightlabs.github.io. And this doesn't apply to custom domains, or give the project owner the ability to force HTTPS-only interaction (HSTS). It's also not documented or announced anywhere, so theoretically it could go away.

But obviously, it's a terrific step, and gives people on Github the ability to host documentation, a blog, or data over a secure channel.

I'd like to keep this issue open until a few things get resolved, in order of descending importance:

• [ ] Github publishes some sort of words somewhere that commit to HTTPS support for *.github.io domains.
• [ ] Will Github give users control over whether HTTP will be auto-redirected to HTTPS and HSTS set? (or will Github just start defaulting future Github Pages to HTTPS?)
• [ ] Will Github support HTTPS for custom domains?

[queso]

:+1:

[edudemy]

:+1:

[supertylerc]

+1. Would be great for custom domains as well.

[likethesky]

+1 for custom domains! This is 2014 after all and GitHub Pages is awesome. Please consider implementing this for custom domains, GitHub. Even if you require a paid account, I'd be fine with that.

[nschonni]

+1. Would be great for custom domains as well.

Sorry, but how would GitHub support custom domains when a certificate must be tied to the actual domain itself. I might be missing something obvious :wink:, unless you're suggesting GitHub becomes a Certificate Authority.

[likethesky]

@nschonni No, I don't believe GitHub would need to become a Certificate Authority (CA); a user who has (or purchases) for instance a wildcard cert for their domain--from a 3rd party CA like Comodo for example--would use that cert (say, for blog.example.com hosted on Pages) but GitHub would have to allow users to install the user's cert for that purpose and associate it with their GitHub Pages (I'm just guessing here, but probably something along the lines of the CNAME file, where you commit & push your cert to a special place and/or name--obviously it would have to be a non-public location, because it's a .pem & private key, so again I'm fine with them requiring a paid account and/or non open repo--though I'm no security expert, might be best another location than the origin repo). Quoting @captn3m0 above, "Building a secure system for all the certificates and hosting them properly would be hard. But heroku handles this pretty well, so can github."

[rayshan]

+1

[aaronlifshin]

+1

[adamliter]

:+1:

[atomicframeworks]

[queso]

It is worth point out that you can use cloudflare to front your project and put the SSL termination there.

[konklone]

@queso It's unfortunately not possible to do this securely, even with Cloudflare. I blogged about this in April, and have kept the post up to date since:

https://konklone.com/post/github-pages-now-supports-https-so-use-it#using-your-custom-domain

You can use Cloudflare to create an HTTPS connection between user and Cloudflare, but not between Cloudflare and GitHub Pages. GitHub would need to update their systems to support presenting a valid SSL cert for the custom domain to CloudFlare, and....I don't know how they would do that.

As an example, MayDay.us uses GitHub Pages and Cloudflare for their donation campaign, and are potentially susceptible to a MITM between GHP and CF. They've acknowledged this, and have accepted the risk for now.

[paulbutcher]

This announcement from Google makes HTTPS support for pages even more important:

http://googleonlinesecurity.blogspot.co.uk/2014/08/https-as-ranking-signal_6.html

[konklone]

The White House launched a website on GitHub Pages today, using a custom domain, which of course breaks over SSL. Here's what I said to them after @csoghoian raised the issue:

Unfortunately, until they do, GitHub Pages is just not a great hosting platform for production websites with custom domains. There's been no movement from GitHub's end since April, so I'm looking to migrate my own away from GitHub until things change.

[RichardOliver]

This please!

[bguiz]

+1 for HTTPS support for github pages on custom domains

[tzach]

+1 for HTTPS support for github pages on custom domains as well

[matt-cook]

+1 Google announcement makes SSL for custom domains a top priority. For Github Pages to continue to be a viable site host we need a method to apply our own certs, even if it requires a paid upgrade.

[bguiz]

@lookitscook Github pages uses cloudflare, and it looks like cloudflare are planning to offer SSL termination for free for free - so it looks like that won't even be necessary!

[bguiz]

FWIW, I have emailed support@github.com, and here is their response:

Please enable HTTPS for github pages using custom domains

Thanks for the feedback. I'll give this a +1 on our internal Feature Request List. We can't promise if we may add something like this, however your feedback is appreciated.

[likethesky]

Btw, @bguiz, as @konklone points out CloudFlare fronting GitHub Pages still isn't the real deal, free or paid. GitHub needs to allow users to install their certs directly in order to accomplish a truly encrypted site, end-to-end. There's nothing that CloudFlare can do about that fact, it can only be solved by GitHub adding this feature or users moving off of GitHub Pages and on to another solution for hosting.

Fwiw, I also emailed GitHub about 3 weeks ago, and this was their response then:

Thanks for getting in touch! Adding HTTPS for custom domains is definitely something we're thinking about, but we don't have a timeline to share at this point.

That being said, we appreciate the feedback, and I'll certainly pass it along to the Pages team.

Let us know if you have any other questions!

[bguiz]

@likethesky My interpretation of this comment was that now Github support HTTPS on github pages, so enabling Cloudflare SSL termination for custom domain names would be sufficient. Thanks for highlighting this other ticket, I was not aware.

@konklone Keep up the great work persuading Github to add this!

[konklone]

GitHub needs to allow users to install their certs directly in order to accomplish a truly encrypted site, end-to-end. There's nothing that CloudFlare can do about that fact, it can only be solved by GitHub adding this feature or users moving off of GitHub Pages and on to another solution for hosting.

Actually, not quite true, @likethesky -- Cloudflare adds customers' domain names to their certs on demand, so they can give your site SSL without you having to make a cert. (You are ultimately in control of pointing your domain name at Cloudflare, so it's not like Cloudflare can use that cert for anything without your consent.)

GitHub could do something similar for customers that point their DNS in GitHub's direction. That'd both a) make Cloudflare unnecessary, and b) allow those who do want Cloudflare anyway to successfully put Strict SSL in front of GitHub.

[mlissner]

:+1:

[ethicalhack3r]

:+1:

[LandonSchropp]

:+1:

[rmzelle]

:+1:

[punnie]

:thumbsup:

[edulix]

:+1:

[nquinlan]

:+1:

[epistrephein]

:+1:

[wsargent]

With the introduction of free Cloudflare SSL -- https://blog.cloudflare.com/introducing-universal-ssl/ and Google's promotion of sites that use HTTPS, this is something that would be a real win for Github.

[konklone]

With the introduction of free Cloudflare SSL -- https://blog.cloudflare.com/introducing-universal-ssl/ and Google's promotion of sites that use HTTPS, this is something that would be a real win for Github.

Very true. It's worth noting that without configuration changes on either GitHub's or CloudFlare's end (or introducing a custom proxy), using CloudFlare for a GHP site would result in encryption for only the first leg of the journey (user->CF) but not the rest (CF->GHP).

[bguiz]

Very true. It's worth noting that without configuration changes on either GitHub's or CloudFlare's end (or introducing a custom proxy), using CloudFlare for a GHP site would result in encryption for only the first leg of the journey (user->CF) but not the rest (CF->GHP).

Given that everything served on ghpages consists of static files, and the source for these are freely viewable by browsing the gh-pages branch from the project page anyway, is the diminished security really of any consequence?

[konklone]

Given that everything served on ghpages consists of static files, and the source for these are freely viewable by browsing the gh-pages branch from the project page anyway, is the diminished security really of any consequence?

I think it's as important to have it encrypted all the way as it is to have it encrypted at all.

One example where a static site was sensitive and inappropriately (in my opinion) used CF over GHP is MayOne.us. Their donation form was served from GitHub Pages through CloudFlare. The donation form posted to a server hosted elsewhere, but a MITM could have replaced the form code with something malicious that would have gotten access to lots and lots of people's credit card numbers.

[mlissner]

Given that everything served on ghpages consists of static files, and the source for these are freely viewable by browsing the gh-pages branch from the project page anyway, is the diminished security really of any consequence?

I truly don't expect my users to figure out where the site is on github and compare the values in their HTML to those in the repository. That's madness.

[edulix]

Even if the source code of the "static app" is viewable, TLS is very important folks. If you want to use github to store a single page web application, for example, HTTPS is needed. Do you know that with TLS the URL Path is encrypted? This way, if you go to foo.com/#/reset/password/45645g4y45y, the path ("/#/reset/password/45645g4y45y") is not revealed to an untrusted third party, and a MITM cannot happen so easily. In general, if you use some kind of URL for authentication, you need TLS or you're fucked. And even more generally, to reduce the possibility of MITM attacks or URL information leaking, TLS is needed.

[wsargent]

What @edulix said. TLS / SSL isn't for data at rest, it's for data in motion.

[sinak]

I've had problems trying to get just Full SSL (not Strict) to work with Cloudflare and Github Pages. I opened a ticket with them about the issue, and they pointed me to this Github Issue. Full SSL on Cloudflare should be possible now that https://website.github.io works, no? Has anyone had any luck getting it working?

I know I'm probably being a bit silly, but I don't completely understand how Strict SSL is considerably more secure than Full SSL if the endpoint has a non-self-signed certificate. If website.github.io has a valid certificate - even if it isn't that for website.com - doesn't that prevents against a MitM pretty robustly? I realize I'm probably mistaken, but would love an explanation as to why its less secure.

[konklone]

@sinak I'm reasonably sure I've gotten Full SSL (not Strict) to work with CF and GHP before. But if you're having problems, it could be because GitHub's behavior when CloudFlare asks it for an SSL certificate is completely undefined and could change at any time.

That (and the reason why Strict SSL is more secure than Full SSL) is because CloudFlare isn't making requests to https://website.github.io. CloudFlare's systems aren't GitHub-aware, it doesn't know that your domain actually maps to some *.github.io domain.

So if you set up (say) konklone.io as a custom domain on GHP as I have, and you then add CloudFlare in front of it, then for either Full or Strict SSL CloudFlare will ask GitHub to respond to https://konklone.io and see what it gets.

Right now, konklone.io is a GHP site, and does not have Cloudflare in front of it. In the past, I'm pretty sure I've seen GitHub respond to SSL requests for https://konklone.io with a cert that's only valid for konklone.github.io. This would work for Full SSL, but not for Strict SSL, and doesn't work when visiting it in the browser. But as you can see when visiting it, GitHub is now just not responding to that domain at all when accessed over HTTPS. And so CloudFlare won't connect correctly either if you add it front of a custom domain.

So that's the current state of affairs between CloudFlare and GitHub Pages - you can't even do unauthenticated encryption (not that it would be worth much). Either CloudFlare would have to become GitHub-aware, or GitHub would have to become CloudFlare-aware, for the connection to work.

[jayschwa]

:+1:

[mat-0]

+1

[dalanmiller]

:+1:

[ryanseys]

:+1: