Please petition GitHub to support HTTPS on GitHub pages
gist.github.comThis is a little weird to me, because it's so easy to host your site a multitude of different ways. The notable thing about GH is its free, which makes complaining about it not having the one feature you want so odd. If you want that feature, pay the buck or two it will cost to host your site on CloudFront with something like Stout [1].
You can as well deploy on OpenShift. They provide 3 small gears for free and allow SSL for bronze accounts (require credit card info, but no payments until you go over free limit).
Github provides an all in-one hosting solution for Open Source projects. You can host code, bug tracker, binaries, and the project website all on Github. I use it to host http://postgresapp.com, for example. It's extremely convenient.
But there is one big gaping security hole: If your project page is served over plain HTTP, and people click on the download link, they are vulnerable to a man-in-the-middle attack. An attacker could change the link to point to a malicious binary instead.
The only way to prevent this is to make sure that your customers don't access your website over HTTP. And this is why HTTPS support for Github pages is important.
Can't a MITM change the DNS for "postgresapp.com" to one of their servers, regardless of HTTPS?
No. If the client connects via HTTPS, it will only connect to a server that presents a valid cert.
We provide both SNI based SSL (starting at $9 including the cert) and full SSL ($49) with CDN based hosting at https://www.netlify.com
As many other has noted, even when once in the future you'll be able to rely on free certificates from Let's Encrypt, serving millions of sites with different certificates (that needs to be replaced every 90 days) adds lots of complexity to any CDN based infrastructure and cost real money.
Apart from that, if you do just SNI based SSL you have to add support costs for explaining to people that don't know the implications, why things like some automation tools, old Android browsers, IE on Windows XP, etc, breaks.
And if you do full SSL you need to allocate lots of IP addresses at each CDN PoP which is expensive.
The certificate is just a small part of the equation when you're offering CDN based SSL.
Ironically, Stout does not support SSL "out of the box": https://github.com/EagerIO/Stout#ssl
Why is securing the web a hassle? Is it just that the certificate trust chain is so fluxored? (Crockford has an interesting perspective here in recent talks)
Thats another thing to configure and worry about though, especially if its just for open source side projects which can be hard to justify spending $ on.
Thats another service you have to monitor to see if its continuing, another service to be hacked, another account user/pass to have.
There's also a multitude of easy ways to host your own git repository and a bug tracker.
However, I prefer to use GitHub so that I have all of it in one place, including the website, and I don't have to spend time managing the infrastructure.
Although they do have free accounts, Github is not completely free. A lot of developers like myself use the paid plans simply because we go over the limits of the free accounts and use it for work (private repos).
You can use CloudFlare with a custom domain in front of Github Pages. It works. I do this for https://github.com/leighmcculloch/5tweets.com which you can see SSL'd at https://5tweets.com.
Yeah but someone can still get between cloudflare and github pages since the traffic between the two end points would still be unencrypted and thus open to MITM..
Actually GitHub have ssl on their username.github.io domain so you can have full ssl from cloudflair back to GitHub.
Which unfortunately doesn't work with CloudFlare on a different domain because it sends the custom domain Host header.
You can use a Page Rule to override this host header with whatever you like: https://support.cloudflare.com/hc/en-us/articles/206652947-U....
Enterprise plans only. I thought "do all of this for free" was implicit in the request to GitHub.
yes, but it's static public pages. it's a pretty big stretch. it's not like users are POSTing confidential data up to your site.
You may well be hosting or linking to builds though, and if someone could replace a popular project's binary builds with one that'll compromise any machine its installed on that's a pretty big deal, especially if some of those machines are production servers.
Actually Cloudflare supports SSL on the backend (as a paid feature) so the only place it could be MITMed is in their network. I'd still like to see it a bit stricter in that I can specify my own self-signed CA that they validate against.
https://blog.cloudflare.com/introducing-strict-ssl-protectin...
There's nothing "paid" about specifying how we connect to your origin (i.e., with HTTPS or HTTP). This setting is available to all plans, free or otherwise.
During onboarding we attempt to establish a connection to your origin using HTTPS. If successful (i.e., your http daemon is listening on TCP 443, speaks TLS, and presents a certificate), we'll default you to using "Full" mode; if not, "Flexible" mode will be set.
Either way, this setting can be changed at any time: simply log in and click the Crypto app in our top level nav. The setting you are looking for is the first one presented on the screen.
In terms of your second comment, we're planning on rolling out a simple way for you to install a free CloudFare-signed certificate on your origin and use that in Strict mode ("Full" with full chain validation). Don't have a GA date for this yet, but it will be announced on our blog once available to all (still in beta).
Source: CloudFlare TLS PM
But you can download stuff you've uploaded and check that everything's in order, right?
and doesnt work in older browsers - free cloudflare cert is ECDHE
IE 6, Android 2.X and IOS 3.X...
I feel like a github project page is unlikely to have a lot of visitors running IE 6.
As some who cares both about accessibility on the web and security, what up-to-date browsers don't support ECDHE and what else would be reasonable to support as well?
probably nothing up-to-date, hence I wrote older :) Opera 12.xx being one of the older browsers that works 99% of the time, except EVERY SINGLE page with Cloudflare cert
What makes matters worse is CloudFlare lying about support level: https://support.cloudflare.com/hc/en-us/articles/203041594-W...
They claim Opera 8, 2005 browser supports ecdhe.
At this point anyone using Opera 12.xx must have pretty low expectations of the web though, right? Even if it is really _only_ CloudFlare, they must be used to seeing that?
so far its only been hobby/torrent/scam sites using free cert, nothing you would hesitate opening in a webproxy.
Ill switch browsers when I can open ~100 tabs without eating 8GB of ram (blink engine), Opera 12.17 does it at <2GB, not to mention being able to configure everything per domain (js,blockers,cookies etc).
That listed was originally created based on minimum requirements for SNI. I've gone through recently and documented where versions need to be adjusted "up" based on requirement for ECDSA support. These changes will be posted as part of some other housekeeping work I have planned for cloudflare.com/ssl.
FYI, when Let's Encrypt goes public in a week, you'll be able to get free certs without having to install anything by using https://gethttpsforfree.com
Fun fact, the website is just a reverse proxied github static page: https://diafygi.github.io/gethttpsforfree
I'd love to see SSL support on custom domains as well, but I know there are a couple of reasons why it hasn't happened already:
1. GitHub Pages likely isn't a core focus for GitHub, however useful it may be
2. GitHub Pages is currently completely interface-less, relying only on an automated build system running each site through Jekyll and deploying it. In order to support custom certificates, they would need to build an interface for certificate uploading/maintenance (and of course putting the certs & keys into the repo, like the current CNAME system, won't work).
GitHub Pages does have an interface, being the user's or the project's profile. You already need to activate GitHub Pages (it can even auto-generate stuff for you) and you need to tell GitHub your public SSH key in order to let you push things into your GitHub Pages enabled repository, right?
Also I hate the CNAME file, as I always forget what to do - should it be a naked domain, should it have www in front, can I specify multiple domains and so on and I always have to reach for their documentation.
It's not a core focus for GitHub, but it's a nice add-on and such things have been keeping many of us on GitHub.
> In order to support custom certificates, they would need to build an interface for certificate uploading/maintenance
With Let's Encrypt (mentioned in the issue) it could be 100% automated with free certs.
If there are hundreds of thousands of these certificates, you will need a custom ACME client anyway. It is not trivial even with a presence of SNI.
Eh, ACME isn't that complex. I wrote a fully automated client in less than 200 lines of python.
An HTTP client that gives a simple automated response is easy to write. An HTTP client that gives simple automated responses to 10,000 connections every second is not easy to write.
(Disclaimer: That said, I haven't seriously assessed the scalability of typical ACME clients. I would appreciate any hard number for them.)
The ACME client only has to run once every 90 days, to validate domain ownership and retrieve an updated certificate. After that, the certificate can be stored on and loaded from disk - the same way most of the files being served are probably stored.
It's true there might be some added complexity, as the private keys will need to be stored securely. And session resumption data, if you need to support that. Doesn't seem like an insurmountable problem, though.
+1
But are you guys seriously going to spam github/contact or support@github.com ?
Because if that was my inbox. I'd be pissed looking at thousands of emails that contain the same body.
Makes it super easy to filter out and delete though...
I agree with imbriaco's sentiment from the linked discussion - using a CDN or some other host that supports SSL to host your static site is a good solution. I recently migrated my GitHub pages site to Amazon S3 and Cloudfront. I had to buy a cheap Comodo SSL certificate and upload it to AWS to get it working with my custom domain, but the documentation[1] was good enough that it didn't take me very long at all.
[1] http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...
What's missing in all that is that they are talking about HTTPS for custom domains, username.github.io supports HTTPS already.
Maybe let people star a dedicated repo instead of sending an email to github.
While GitHub has a free account, it gets quite expensive when you start paying. And GitHub Pages is a complementary add-on and many of us stayed on GitHub because of nice things like this. I do agree that it isn't their core focus and that people could host their stuff somewhere else for cheap.
However there is something to be said about making encrypted connections the standard. Chrome and Firefox will only support encrypted HTTP 2.0 connections. So if GitHub Pages does not provide HTTPS for custom domains, then it won't support HTTP 2.0. Adding HTTPS support is also the right thing to do given the recent attacks on privacy.
Yes, GitHub Pages is a free add-on that isn't their competency, but in my opinion they should either drop it completely, or support HTTPS. Because otherwise they are keeping the web back due to their popularity.
Yeah, and please send me a free flying car while you are at it.
Obviously everybody would like that, but it's not as easy as it seams. As github pages, technically are virtual domains, they share the same ip with many other pages, if you want to support https, you need to serve either each page on a different ip (not free), or they need a to configure multidomain ssls (which everytime they need to add a new domain, that means they have to reset the certificate for the other domains on the same ip), and I think there is a limit on the number of domains that can share the same ip - citation needed - . And all of this for free.
Want SSL on gh pages, setup a proxy infront of gh pages.
Or you can use a web server that supports SNI. You'd lose android 2.x and ie@winxp clients though, but those will be lost anyways soon due to outdated cipher suites and certificate hash algorithms
> configure multidomain ssls (which everytime they need to add a new domain, that means they have to reset the certificate for the other domains on the same ip),
Sorry should've called it SNI.
Multidomain certs are not the same thing as SNI.
Thank you, learned something new today.
As github pages, technically are virtual domains, they share the same ip with many other pages, if you want to support https, you need to serve either each page on a different ip (not free), or they need a to configure multidomain ssls
If you use SNI, you can serve multiple SSL-protected domains from a single IP. Happily, this is supported by 97.6% of web browsers these days: http://caniuse.com/#feat=sni In fact, most browsers which don't support SNI have been end-of-lifed and are no longer receiving security updates. So unless you still need to support Windows XP or Android 2.x, you can now generally host multiple SSL-protected domains on 1 IP address.
No, you also have SNI (Server Name Indication), it totally solve this problem.
The only downside is that IE on Windows XP doesn't support it. But for a free service it's good enough.
Its quite a co-incidence that I scouted for an answer for this today while I was setting up SSL for my gh-pages. As already pointed out by some comments, its not quite as simple as we think it is to have GitHub extend SSL for its pages. Its for the same reason that Tumblr doesn't allow SSL support for custom domain either. IMHO, CloudFlare is probably the simplest workaround to get SSL enabled for your gh-pages. Link on how to https://me.net.nz/blog/github-pages-secure-with-cloudflare/
What's missing is, why? It's a static site, so you won't get any real privacy about what you're reading. If you have binaries to distribute, you have other features for releasing them that let you use TLS.
Script injection (see Comcast a few weeks ago), page manipulation (eg. pointing at download links with malicious side-load), keyword-based filtering (HTTP inspection). If you're using non-default DNS servers, you also get privacy on which site you're reading: all HTTP request headers also get TLS protection, which includes hostname, path, etc. And while outside of Tor, there's no protection for the IP address (so third parties can know you're reading a page on github), "a site hosted on github" encompasses a wide variety of content.
> "a site hosted on github" encompasses a wide variety of content.
That doesn't help, you can easily fingerprint a page from secondary requests or incoming/outgoing links.
AFAIK the hostname is not encrypted when using SNI
Well in the past China has intercepted non-https connections and inserted malicious javascript that joined the users into a botnet that launched a DDOS attack on github.
The "Great Cannon".
It's a valid point as the content of the site itself can still be manipulated if not served securely. However that being said, it does seem like a very low risk situation and if needed there are tons of other options.
Most of the Pages sites are just about projects themselves so the readme.md and wiki in the github repo can already serve over https and do the job just fine.
I also have my personal website on GH pages + Cloudflare. If it is for a static web site I think it is ok, and thanks to both companies that gives us this service for free.
If you pretend more you can pay and use AWS or some other service.
Of note guys there's a little ! icon button in the top of the page to report this gist. It's basically encouraging spam and as everyone has pointed out, is likely not technically sound.
Worth noting: https works on yourname.neocities.org.
just likes it does on yourname.github.io. (Since that just requires a wildcard cert)
I add SSL through a proxy to GitHub pages.
Been wanting built in ssl forever.
Isn't Github Pages hosted on S3? That would explain the lack of TLS on custom domains.
Anyway, this is a very major security flaw. Lots of software uses Github pages for the project website. If you put a download link on an unsecure page, you are putting all your customers st risk.
Githug Pages is their own infrastructure for hosting files and static sites: http://githubengineering.com/rearchitecting-github-pages/
Also the download files themselves can be hosted on Github repos as releases which supports TLS.
Hosting the downloads themselves via HTTPS is completely useless if the link to that file is transferred over HTTP.
Link to the repo/releases page...
Jesus Christ, you really don't understand, do you?
If the original website is insecure, everything could be faked, including the link to the releases page.
If HN readers don't understand this, who does?