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, 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]

👍

[waldoj]

👍

[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]

👍

[edudemy]

👍

[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 😉, 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