Add HTTPS support to Github Pages including custom domains #156

Open
konklone opened this Issue Mar 8, 2014 · 414 comments

Projects

None yet
@konklone
konklone commented Mar 8, 2014 edited

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
konklone commented Mar 8, 2014

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
konklone commented Mar 8, 2014

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
captn3m0 commented Mar 8, 2014

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
patcon commented Mar 8, 2014

πŸ‘

@waldoj
waldoj commented Mar 9, 2014

πŸ‘

@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
queso commented Apr 29, 2014

πŸ‘

@edudemy
edudemy commented May 9, 2014

πŸ‘

@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
rayshan commented Jun 29, 2014

+1

@rayshan rayshan referenced this issue in bower/bower.github.io Jun 29, 2014
Closed

SSL certificate for bower.io & subdomains #45

@aaronlifshin

+1

@emka emka referenced this issue in osmbike/osmbike.github.io Jul 15, 2014
Open

SSL certificate #3

@adamliter

πŸ‘

@atomicframeworks

@queso
queso commented Jul 25, 2014

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
bguiz commented Aug 13, 2014

+1 for HTTPS support for github pages on custom domains

@tzach
tzach commented Aug 13, 2014

+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
bguiz commented Aug 16, 2014

@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
bguiz commented Aug 16, 2014

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
bguiz commented Aug 16, 2014

@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.

@rlidwka rlidwka referenced this issue in expressjs/expressjs.com Aug 24, 2014
Closed

https://expressjs.com/ does not responding #204

@mlissner

πŸ‘

@jimmycuadra jimmycuadra referenced this issue in litaio/lita Aug 31, 2014
Closed

Fix docs.lita.io #60

@ethicalhack3r

πŸ‘

@LandonSchropp

πŸ‘

@rmzelle
rmzelle commented Sep 9, 2014

πŸ‘

@punnie
punnie commented Sep 16, 2014

πŸ‘

@edulix
edulix commented Sep 19, 2014

πŸ‘

@nquinlan

πŸ‘

@epistrephein

πŸ‘

@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
bguiz commented Sep 30, 2014

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
edulix commented Sep 30, 2014

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
sinak commented Sep 30, 2014

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
jayschwa commented Oct 6, 2014

πŸ‘

@jimmywarting

πŸ‘

@ChelseaStats

+1

@dalanmiller

πŸ‘

@ryanseys
ryanseys commented Oct 7, 2014

πŸ‘

@henhouse

πŸ‘

@Miladiir

@sinak Probably to late, but here you go:

Self signed certificates provide a secure connection to the server. Non-self signed certificates (as in certificate issued by authority) are even more secure, as they provide a secure connection to the server AND the server is confirmed to be real.

To understand this issue imagine the following: Which would you trust more, a certificate for github.com signed by me or a certificate signed by verisign or globasign?

On the issue: I can do the full ssl thing, however I end up at a page saying that the system doesn't recognize the url. Implementing this would be a huge deal! For now I am just redirecting my page to another server with a proper ssl setup.

@sinak
sinak commented Oct 24, 2014

@Miladiir That makes sense, and I now understand why self-signed certificates are less secure. Thanks.

@konklone: I think I'm probably best off responding to your example with my own setup. You said:

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.

Here's my example: I have my stopwatching.us and optin.stopwatching.us records as CNAMEs pointing to efforg.github.io. efforg.github.io supports HTTPS, so I would imagine that Cloudflare would be able to enable Full SSL. But when I enable that option, I get an HTML page saying "Domain stopwatching.us not found."

I guess it feels like your sentence "CloudFlare's systems aren't GitHub-aware, it doesn't know that your domain actually maps to some *.github.io domain" isn't true if the DNS record is a CNAME.

@konklone

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?

@sinak - If CloudFlare doesn't validate the certificate at website.github.io, then it doesn't matter whether the certificate is valid or not. So even if you have a valid cert, it could be trivially replaced with a forged cert and CloudFlare wouldn't care. This is why Full SSL (non-Strict) is weaker than Strict, no matter what certificate is used.

But when I enable that option, I get an HTML page saying "Domain stopwatching.us not found."

I guess it feels like your sentence "CloudFlare's systems aren't GitHub-aware, it doesn't know that your domain actually maps to some *.github.io domain" isn't true if the DNS record is a CNAME.

I don't think that's correct. You get an HTML page saying "Domain stopwatching.us not found" because that's what GitHub's servers are telling CloudFlare. CloudFlare is not GitHub-aware, and is not asking GitHub for the content at efforg.github.io, but the content at stopwatching.us. GitHub's servers are not configured to respond to the custom domain over port 443, so they return an error.

I'm inferring from the outside here, and it'd help to have someone from CloudFlare clarify how this works. But my understanding is: when you give CloudFlare a "CNAME", that's not literally set as your domain's CNAME. It's helpful for you to think of it as a CNAME, because CloudFlare internally uses it to resolve which server it should be serving content from. (You can't set the CNAME to the same domain, because that would be circular and give CloudFlare no information.) CloudFlare resolves efforg.github.io to a GitHub IP address, and then asks that server to give it content corresponding to stopwatching.us, over port 443. (This is likely accomplished through the Host header over HTTP, and/or the servername flag in SNI for SSL.)

If you've got Strict on, then it will validate the cert that your server has installed for stopwatching.us and verify that the cert was issued for that domain name. Without Strict, any cert will do, but the server at hat IP will still have to respond properly to requests for stopwatching.us over port 443.

If CloudFlare used your CNAME's domain to validate the certificate, it wouldn't be validating that the origin's certificate was valid for the domain it's ultimately serving for the customer. The only way CloudFlare would do that is if it made an exception for GitHub Pages, which means it would have to be GitHub-aware. Right now, that's not the case.

@konklone

I've reproduced the process CloudFlare goes through for either Strict or non-Strict configurations,by testing https://theunitedstates.io, which is hosted on GitHub Pages.

Here's my "DNS" configuration in CloudFlare for the domain:

cname

Domain set to use "Full SSL (Strict)"

Here's what it looks like with "Full (Strict)" enabled -- CloudFlare can't even make the handshake work. (It's certainly not requesting data from https://unitedstates.github.io.)

handshake failed

You can reproduce this yourself by trying to visit the HTTPS version of a custom domain on GitHub Pages that is not hosted on CloudFlare - for example, https://konklone.io. It just hangs.

Domain set to use "Full SSL" (non-Strict)

Now, here's what my domain looks like with just "Full" enabled, non-Strict -- the same "unknown domain" error you got:

unknown domain

Here's how to demonstrate what's happening, and what CloudFlare sees. If you do a DNS lookup on GitHub Pages' server for unitedstates.github.io, you can get one of GitHub Pages' Fastly IP addresses:

$ nslookup unitedstates.github.io

Server:     127.0.1.1
Address:    127.0.1.1#53

Non-authoritative answer:
unitedstates.github.io  canonical name = github.map.fastly.net.
Name:   github.map.fastly.net
Address: 23.235.39.133

If you then add this line to your /etc/hosts file to force your computer to resolve theunitedstates.io to that IP address:

23.235.39.133 theunitedstates.io

And then visit https://theunitedstates.io (in an Incognito window, if you're using Chrome, to clear the DNS cache), you'll get an invalid cert (in fact, it's GitHub.com's main cert!):

invalid domain

And if you click through that error, you'll get the same "unknown domain" error that CloudFlare saw, from GitHub Page's server:

got it

Conclusion

Those are the mechanics involved, and why right now, with GitHub's current server and CDN configuration, you cannot get a secure end-to-end connection to GitHub Pages' CDN.

Also, bear in mind -- even if we did manage to get a secure connection to GitHub Pages' CDN -- Fastly -- there's no visible guarantee that content is encrypted between Fastly and GitHub itself.

@hnrch02 hnrch02 referenced this issue in twbs/bootstrap Oct 24, 2014
Merged

Use HTTPS in CDN URLs in _config.yml #14192

@paddingme

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

@hamishcampbell

πŸ‘

@bhanuc
bhanuc commented Oct 28, 2014

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

@why-jay
why-jay commented Nov 2, 2014

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

@garrettboatman

+1,000,000. I have no idea why at least flexible SSL isn't supported yet.

@johntfoster

πŸ‘

@parin95
parin95 commented Nov 15, 2014

+1 for HTTPS support for github pages on custom domains

@wsargent

https://letsencrypt.org/

@timothybasanov

It would be really cool to have an HTTPS on my Domain using GitHub to serve content.
I realize that it's hard to solve problem.

I'm willing to share my private key for SSL certificate so GitHub would establish HTTPS session on my custom domain. Even if I would need to have a private repo for that. Even storing it in a public one provides some guarantees for the end user (assuming that nobody modifies, only inspects traffic in flight).
Assuming that client supports SNI (of course) it's theoretically possible.

And yes, I understand that maintain a key infrastructure on servers that terminate TLS would be a huge pain for GitHub. Paid option to limit number of certificates that you need to store?

@cben
cben commented Nov 20, 2014

SNI is already assummed β€” all GH pages are served from about 4 IPs. (At
least all custom domain pages.)

Putting your cert private key in public is really bad, turning it into
security theater.
Assuming MITM is tricky to pull off made some(?) sense 15 years ago but not
in the age of coffee shop wifis and Firesheep, not to mention three-letter
agencies...
Even a sporadic active attack may compromise lots of other passively
inspected communication by that user via stealing/setting cookies/phishing.
Worse, I think(?) that if the encryption didn't feature Forward Secrecy, a
passive observer having the secret key can just decrypt everything.

@timothybasanov

Nah, they are using only one certificate now, that covers all the subdomains.
But this is impossible in case of user-provided domains.

@stevenroose

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

@mlacorte

+1 for a native (non CloudFlare) solution.

I can get by with using the https://mlacorte.github.io domain for my personal blog, but I'd much rather be able to use my sexy https://blog.michaellacorte.com. I imagine this would be a dealbreaker for many other people/organizations.

@philsturgeon

Current progress.

1604591_700b

@adrifelt

πŸ‘ I'd gotten excited about setting my new site up with GH pages + custom domain, but full end-to-end HTTPS support is important for me so I'm now stuck.

@konklone

To the thread: what would be a useful thing to do here?

I can imagine an nginx proxy snippet, or one-button-deploy Heroku proxy server, that would do the work CloudFlare does not -- knowing to proxy https://mydomain.com to https://me.github.io/maybe-a-path-prefix/, and to validate the github.io certificate.

@patcon
patcon commented Nov 28, 2014

@konklone πŸ‘ for unblocking ourselves

@giodamelio

πŸ‘

@CumpsD
CumpsD commented Dec 6, 2014

Chiming in with the many voices before me. We just moved a year worth of interal work at our company onto GitHub to open source it, combined with a GitHub Pages frontend. Https is something we care about a lot, and would love to be able to enable it on our custom domain.

@asgrim asgrim referenced this issue in phphants/php-south-coast-2015 Dec 9, 2014
Closed

Create 301 redirect to HTTPS #7

@sikachu
sikachu commented Dec 31, 2014

πŸ‘ to this as well.

I really don't know all the details, but I'm curious why I can point CloudFlare to, say, foo.herokuapp.com, and it works under Full SSL mode. I think GitHub is already serving the right SSL certificate, but they just need to fix their app router ... somewhat.

@likethesky

@konklone are you saying that if I'm already on Heroku, that using my wildcard cert there I could possibly direct back to mysite.github.io and have end-to-end (strict) SSL/TLS ? IOW, I'm not using Cloudflare, I just want strict SSL for users who hit my GH Pages site. I'd be happy to run some experiments on a Heroku deploy at some subdomain on my site (I have a wildcard cert), if you think it'd be worth trying!

@sikachu this works because Heroku provides a fully valid wildcard cert for *.herokuapp.com (and possibly because Cloudflare is also 'Heroku aware'). Note that @konklone mentions in prior replies that CF is not 'GitHub Pages aware', I'm not sure whether that's part of why Heroku works in this case or not. For sure, also, Heroku does offer users the ability to serve their own certs, unlike GH Pages, which is what all of these +1s here are asking for--as I'm sure you're already aware--which is: for GitHub Pages to step up and do what Heroku has already done: namely, to allow user certs to be installed and used for their custom domains, so true strict SSL is possible--fully end-to-end with no MITM attacks possible (I dislike the fact that there's even such a name as full or flexible SSL, because let's be frank, it ain't SSL/TLS at all!)...

@konklone
konklone commented Jan 1, 2015

@sikachu Are you under Full SSL with Strict enabled? If so, can you share your CloudFlare "DNS" configuration?

@likethesky I think you could definitely set up a Heroku app that received traffic at https://yoursite.herokuapp.com and proxied it behind the scenes to https://yoursite.github.io/whatever/ (assuming that your proxy library was set to validate the HTTPS connection it's proxying to -- for example, nginx only added this functionality in the last year). Your canonical, public URL would be a herokuapp.com URL, but if that's fine with you, you should go for it.

@cben
cben commented Jan 2, 2015

If one would be fine with a FOO.herokuapp.com url, then a FOO.github.io
url should also be acceptable (IIUC /whatever suffix can be avoided by
using Organization rather than User Pages).
The whole point of a heroku proxy is that Heroku does allow you to
provide a cert and serve FOO.com.
2.

A heroku proxy forwarding requests to github is unlikely to perform as
well as just serving the data from heroku. (In particular a freebie 1-dyno
app will lose the CDN benefits of GH Pages.)

All it gives you is the convenience of automatic deploy when you push to
gh-pages branch, but pushing to heroku remote is practically as easy.

So I don’t see why anyone would run such a proxy.
It becomes more interesting to run a single proxy which can serve many
projects, or many versions.
Many projects doesn’t work well because of certs and trust;
for many versions I am contemplating running a rawgit.com clone under my
own domain, giving users ability to test any commit (including branches and
forks).
​

@scw scw referenced this issue in JuliaLang/julialang.github.com Jan 20, 2015
Open

Enable TLS / HTTPS access to the site #198

@roughani

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

@wking wking referenced this issue in swcarpentry/workshop-template Feb 3, 2015
Closed

Serve pages over HTTPS? #152

@mholt
mholt commented Aug 31, 2016 edited

@zmwangx I think the suggestion by @TPS was not for GitHub users to install and run Caddy themselves but for GitHub to use (it? something like it?) for serving GitHub pages.

I know of Caddy instances serving thousands of static sites over HTTPS each with different domains and all on the same machine, and Caddy can indeed scale to many nodes.

(Beware the apparent spamming campaign by Netlify, which recent comments seem to be a part of.)

@vgmoose
vgmoose commented Sep 1, 2016

@zbeekman Three days have passed since I switched my domains over to Netlify, and for me there does seem to be a marked decrease in speed. I'm hoping this improves over time.

If anyone wants to run speed tests, here are a few custom domain URLs:

Provider URL
GH Pages http://hbas.vgmoose.com/
Netlify http://hbas2.vgmoose.com/
Netlify+SSL https://hbas2.vgmoose.com/
Digital Ocean http://hbas3.vgmoose.com/

All of those sites use vgmoose/hbas/gh-pages as their source. Netlify automatically updates via a read-only deploy key when a new push is made to that branch. The above is using the "Netlify Pages" plan although there's another plan for open-source projects that is also free.

I suspect that the results may very from region to region, so I'm interested in seeing how it stacks up. The last URL is a $5/month Digital Ocean droplet that I pay for, which I've put up mostly for comparison. I do not have any results in comparison with CloudFlare.

@mholt According to my history, I found out about Netlify by googling "static https sitefree" (yes, with no space) out of desperation around noon on August 29th, after which I switched over and made my comment here. I can assure you I'm not affiliated with them in any way, only found their service free and useful. I am flattered however that you would think that anybody would pay me to plug anything. πŸ˜„

https

At worst, I'm entitled for demanding custom domain + SSL hosting from Github from their free service, but that is what this issue's about. It's upsetting that Github offers free SSL, and free custom domain support, but not a combination of both. I've wanted this for some time and wanted to share it with anyone else who may be frustrated as well.

@frankrousseau

Providing a free certificate for each domain is not an easy task.Β Maybe that Github could do something with Let's Encrypt. But what could be nice would be to allow the user to set his own certificate.

@mitar
mitar commented Sep 1, 2016

Providing a free certificate for each domain is not an easy task. Maybe that Github could do something with Let's Encrypt. But what could be nice would be to allow the user to set his own certificate.

I think this would be a nightmare to distribute over a CDN.

@tebruno99

You don't have to go far to see this implemented correctly. Thanks @gitlab. Its not hard, you attach what ever cert you want to the page.

@mitar
mitar commented Sep 1, 2016

GitLab does not use CDN, no?

@marcoslater

@mitar GitLab sadly does not have a CDN, no. I recall reading a thread they had where they discussed potential use of CloudFlare for it. Not sure what has come of it, though.

@mitar
mitar commented Sep 2, 2016

Yes, but using custom SSL certificates for a bunch of domains with CDNs will be tricky technical implementation to do properly.

@tebruno99

I think CDN or no is up to you. You can wrap any http service in a CDN. This feature request is just asking Github to provide custom SSL certs for the custom domains they allow to be pointed at their own services.

@AnthonyMastrean AnthonyMastrean referenced this issue in AnthonyMastrean/anthonymastrean.github.com Sep 2, 2016
Open

Let's Encrypt! #36

@wybiral
wybiral commented Sep 3, 2016

I just want custom domains to support HTTPS. Even if I have to supply my own certs.

Some browser features are disabled outside of secure domains. I just hit a snag trying to use getUserMedia on chrome.

@paulmillr

This is a very important milestone. Today Chrome 55 introduced a flag which effectively displays all HTTP websites as non-secure.

The flag is going to be enabled by default in the future. If GitHub does not introduce the proper SSL encryption support, it's going to be quite a challenge to convince the users the websites do not have actual problems.

1 jc2nafnes5ss0d_e0pqwqg

@sampablokuper

@paulmillr wrote:
This is a very important milestone. Today Chrome 55 introduced a flag which effectively displays all HTTP websites as non-secure. The flag is going to be enabled by default in the future.

@erickpatrick

It would be interesting if GitHub comes up with something like Medium did for their custom domain HTTPS support.

They (Medium) do all the heavy stuff and I just had to add one CNAME and twelve A records. In a matter of two hours everything was working.

@dwavid
dwavid commented Sep 20, 2016

This. 1000 times this. Make it happen, GitHub!

@kaaloo
kaaloo commented Sep 21, 2016

I learned recently about firebase hosting which does seem to offer custom ssl (haven't tried yet) and could be an alternative place for static sites.

@zimbatm
zimbatm commented Sep 21, 2016

Gitlab Pages is also free but you have to upload your own SSL certificates (got a free-one from Gandi.net with the domain).

@Gottox Gottox referenced this issue in voidlinux/voidlinux.github.com Sep 22, 2016
Closed

Wrong SSL certificate at voidlinux.eu #37

@itaysk
itaysk commented Oct 3, 2016

Came here to support this issue. I have just migrated my blog to GH Pages and my custom domain, and found out too late it doesn't support SSL...

@lixonic
lixonic commented Oct 4, 2016

@Chi-Yu
Chi-Yu commented Oct 11, 2016

Having Github Pages support Let's Encrypt would be awesome but is likely a difficult task.

Since all the custom CNAME entries point to Github and they are obviously already stored somewhere, Github is sort of "in control" of the domain names and could probably request Let's Encrypt certificates on the repository / organization owner's behalf.

However, I imagine rolling out a certificate with I don't know how many alternative names for each and every CNAME pointing to GitHub Pages to be somewhat difficult if not impossible, especially since such certificate would have to be updated whenever somebody adds a new CNAME (which probably happens every couple of minutes?).

I'm not even talking about rate limits (which Let's Encrypt has) and I don't know whether a certificate can even hold that many SAN entries.

Regarding Chrome:

Didn't they say that they only wanted to highlight insecure pages if those pages contained some sort of form? None of my Github Pages use forms so I should be "safe" (or rather "unsafe"? scnr), right?

@libeclipse
libeclipse commented Oct 11, 2016 edited

Chrome will eventually start showing warnings for all http traffic and then the other browsers will follow.

Netlify, as mentioned previously, is an excellent alternative to native SSL support. I'm still hosting my site on Github but now I have a CDN and an A+ rating from SSLLABS. https://www.ssllabs.com/ssltest/analyze.html?d=libeclipse.me

On 11 Oct 2016 05:52, "Chi-Yu" notifications@github.com wrote:

Having Github Pages support Let's Encrypt would be awesome but is likely a
difficult task.

Since all the custom CNAME entries point to Github and they are obviously
already stored somewhere, Github is sort of "in control" of the domain
names and could probably request Let's Encrypt certificates on the
repository / organization owner's behalf.

However, I imagine rolling out a certificate with I don't know how many
alternative names for each and every CNAME pointing to GitHub Pages to be
somewhat difficult if not impossible, especially since such certificate
would have to be updated whenever somebody adds a new CNAME (which probably
happens every couple of minutes?).

I'm not even talking about rate limits (which Let's Encrypt has) and I
don't know whether a certificate can even hold that many SAN entries.

Regarding Chrome:

Didn't they say that they only wanted to highlight insecure pages if those
pages contained some sort of form? None of my Github Pages use forms so I
should be "safe" (or rather "unsafe"? scnr), right?

β€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#156 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AIhzn9xMBNTMh2pGt6Uv8XzSH5PQrnxTks5qyxYLgaJpZM4Bn9Ar
.

@fguillen

πŸ‘

@she-dev
she-dev commented Oct 14, 2016

❀️

@kenkendk kenkendk referenced this issue in duplicati/duplicati.github.io Oct 14, 2016
Closed

HTTPS for Website #1

@emilstahl

@libeclipse

Chrome will eventually start showing warnings for all http traffic and then the other browsers will follow.

As @Chi-Yu said, only for pages with password and credit card forms – not all http traffic.

https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html

@libeclipse

@emilstahl

In your own source it says near the bottom:

Eventually, we plan to label all HTTP pages as non-secure, and change the HTTP security indicator to the red triangle that we use for broken HTTPS.

@whmountains

How does CloudFlare do it? I assume if they can do it github should be able to as well.

@TPS
TPS commented Nov 19, 2016 edited

@DanBovey reports that this might be solved by a new section in the project settings which handles custom domains. Can you confirm, @Konklone or anyone else?

@zimbatm
zimbatm commented Nov 20, 2016

@TPS I'm seeing an alternate way to set the CNAME for a repo. Where does it talk about TLS configuration?

@konklone

@TPS: It looks to me like @zimbatm is right -- it's just a new way to set up the CNAME.

In the comment from @DanBovey you linked to, he notes that in order to get TLS, he still needed to put CloudFlare in front of the domain, which has been the status quo for a while.

@david-a-wheeler

+1 https for custom domains.

@petervaro

this issue was opened 2 and 1/2 years ago.. yet nothing has changed so far, still not working.. in 2016, no https for custom domains!

@strugee
strugee commented Dec 5, 2016 edited

yet nothing has changed so far

This is simply incorrect. GitHub recently added HTTPS support for *.github.io sites which, while not a complete solution, is a huge step forward.

Also, as has been mentioned a couple times in this thread, please don't add +1-type comments. If you read the README.md file you'd know that GitHub doesn't monitor this issue tracker, so all your comment did was generate more spam for the people who're subscribed. If you (and @david-a-wheeler) could refrain from +1 comments in the future, that'd be great.

@ploxiln ploxiln referenced this issue in nsqio/nsq Dec 6, 2016
Closed

nsq.io is serving wrong certificate #820

@xgqfrms-GitHub

GitHub Pages site with HTTPS & personal domian

@AnotherKamila

What is the current status? Is anyone at GitHub looking into this?

I have been using Let's Encrypt in production for over a year, and I never had any problems (apart from the ones that were my fault). SNI is already assumed. Therefore I believe there are no unsurmountable obstacles.

The lack of HTTPS support is the one reason that makes me self-host a bunch of Jekyll sites that could be hosted with GH Pages. I'd be willing to donate some money or time to this cause.

@zimbatm
zimbatm commented Dec 12, 2016 edited

Please read this thread and only add a comment if you have something new to add. As a recap here are some facts that make it hard for GitHub to implement this:

  1. GitHub relies on Fastly for doing CDN. That's what makes GitHub pages fast and also protects them from DDoS. Fastly's pricing is $100 per SNI certificate per domain: https://www.fastly.com/pricing
  2. There are a lot of GitHub pages. Let's Encrypt doesn't make every TLS problem magically go away. They have very low rate-limiting per account. Hosting a lot of SNI certs on a single node is not that easy if they all have to be loaded in memory and TLS session maintained between requests.

It's a scaling issue. To make this cost-effective GitHub would have to find another CDN that offers cheaper TLS end-points.

For now the cheapest options are CloudFlare (Free) if you care about latency or putting a cheap VPS (DigitalOcean / Vultr / ... at ~$5.-/month) with Nginx and Let's Encrypt if you care about privacy and users accessing your site over Tor.

For a free service GitHub pages is fantastic.

@konklone

@dorianpenaloza Please read the above thread in full - there are a number of solutions discussed. All of them are incomplete in some significant way (thus this ticket), but a work around might be acceptable for your case.

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.

@arzafran
arzafran commented Jan 31, 2017 edited

Just my two cents:

  • Follow this guide.
  • Keep walking as a secured citizen of the internet.

spoiler alert: it's about cloudflare free setup.

EDIT: keep in mind that this thread it the first result on google when new people is searching about ssl and github custom domains, and the guide I'm pointing to, is from july '16, and I've read the thread in full, and haven't found that exact, and easy to follow guide.

@SirDoctors

@arzafran This issue is currently moving for github to support ssl on custom domains with valid ssl certificates without having to use a third party service like cloudflare.

@arzafran
arzafran commented Feb 2, 2017

@TheDoctorsLife Nice to know! eager to transfer my cloudflare-served domains to an integrated solution within Github.

and just wanted to know, what's up with all those thumbs down? is there any particular reason?

@zmwangx
zmwangx commented Feb 2, 2017

@arzafran Let me quote konklone's comment, immediately above yours, in full:

Please read the above thread in full - there are a number of solutions discussed. All of them are incomplete in some significant way (thus this ticket), but a work around might be acceptable for your case.

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.

You pointed to a solution that's been discussed since as early as 2014, and has been mature for at least the greater part of a year. And you did so with smugness. Your comment didn't add to the discussion, and was kind of an insult to people's intelligence too.

Also, asking about downvotes is sometimes worse than being downvoted.

(Please, don't reply to this.)

@wsnark wsnark referenced this issue in defcon-nn/defcon-nn.github.io Feb 6, 2017
Open

HTTPS вСрсия сайта #26

@cben
cben commented Feb 7, 2017

@TomasVotruba I see you're using Cloudflare.
You had to config it to "Full SSL" but not "Full (Strict) SSL" mode, right?
"Full" is unsecure between Github Pages and Cloudflare (they don't verify it's a *.github.io cert, a MITM attacker could present "evil.com" cert and Clouldflare would accept it).
Your decision whether that's acceptable, but as had been mentioned before, it's not a real secure solution.

Several other services have been mentioned on this thread, I think some are both gratis and end-to-end secure, but this thread remains about waiting/asking for Github Pages native support.

@madrugado madrugado added a commit to madrugado/madrugado.github.io that referenced this issue Feb 7, 2017
@madrugado madrugado FIX: force HTTP due to isaacs/github#156 a55eec8
@NoNameProvided

Guys, stop spamming please! @TomasVotruba your solution doesn't related to this issue, since it has nothing to do with SSL on github pages and also this solutions was discussed before. I mean no offense and I appreciate your work, but it's simply not related, so all the people who subscribed to this issue to be notified when Github pages supports SSL got spammed.

So I ask you and any future commenter to post only if it you have some update on the SSL support for Github pages.

Thanks!

PS: Don't answer this post, please just dont.

@whmountains
whmountains commented Feb 7, 2017 edited
@zmwangx
zmwangx commented Feb 7, 2017

Some of us still enjoy talking about this, even if it's with people who don't fully understand the situation.

You're basically treating this thread like IRC, while it's not. "People who don't fully understand the situation" should just read what people have said before; as long as you're patient enough to read, it doesn't take a lot of technical chops to understand the situation.

You have no right to prohibit us from doing so.

While we can't prohibit you from spamming us, we have every right to ask you to be considerate to other people (and it is within your right to not listen). There are hundreds of participants on this thread, and if I may venture a guess I'd say a thousand or more people are subscribed. We're subscribed for a reason; otherwise, with this much spam we would have unsubscribed long ago.

@gentauro

@whmountains and @zmwangx

xkcd_1357_free_speech_2x

@marcoslater
marcoslater commented Feb 23, 2017 edited

Since this appears to be a widespread issue, I'll post it in here as well.

For those of you using CloudFlare in front of Github Pages, which seems to be quite a few, if you're getting "Error 1014 CNAME Cross-User Banned" errors, there's a quick fix I found for it-

Change your CNAME's from username.github.io to github.map.fastly.net.

github.map.fastly.net is Github's current pages backend, and seems to be serving every pages domain I checked so far. You can check it by querying your github.io domain's DNS records, and it should show up.

Hopefully this helps a few of you who are wondering what the heck is going on with your site. :)

EDIT: I assume this is somehow also related to the other CloudFlare news. Perhaps accidentally broke it whils't firing out patches? Β―_(ツ)_/Β―

@HenrikBengtsson HenrikBengtsson referenced this issue in callr-org/website Feb 24, 2017
Open

Enable SSL / HTTPS for the web server #24

@strugee
strugee commented Feb 24, 2017

@FichteFoll interesting, but that isn't really relevant. That single bug is not really a legitimate reason to reject Cloudflare for this purpose because the truth is every single service you use will contain security bugs - it's just a fact of life. If this was a regular occurrence then that would indicate a systematic problem, but an isolated incident like this doesn't really say much. (One could argue that the fact that Cloudflare introduces the complexity of an HTML parser is problematic, but I don't think that's a compelling enough reason to reject it as a solution.)

@strugee
strugee commented Feb 24, 2017

To clarify: not trying to downplay the severity of this incident, just pointing out that there isn't really a useful response.

@libeclipse

@strugee Regardless of this major security incident, cloudflare really is a terrible solution, for countless reasons that have all been mentioned before.

Use Netlify instead.

@strugee
strugee commented Feb 24, 2017

@libeclipse I agree, I just worry that people will start throwing around FUD and making arguments that don't really hold water.

Again, not claiming that this isn't a major incident (it is), just trying to put it in context for the purposes of this discussion

@konklone

Now that it's been mentioned, further discussion of the issue is off-topic and creating unwanted emails for subscribers. Please don't comment further unless it's to provide new and relevant information that this thread doesn't yet contain. πŸ‘ πŸ”’

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment