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.
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.
Thats another service you have to monitor to see if its continuing, another service to be hacked, another account user/pass to have.
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.
https://blog.cloudflare.com/introducing-strict-ssl-protectin...
I feel like a github project page is unlikely to have a lot of visitors running IE 6.
Fun fact, the website is just a reverse proxied github static page: https://diafygi.github.io/gethttpsforfree
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).
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.
With Let's Encrypt (mentioned in the issue) it could be 100% automated with free certs.
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.
[1] http://docs.aws.amazon.com/AmazonCloudFront/latest/Developer...
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.
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.
Sorry should've called it SNI.
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.
The only downside is that IE on Windows XP doesn't support it. But for a free service it's good enough.
That doesn't help, you can easily fingerprint a page from secondary requests or incoming/outgoing links.
The "Great Cannon".
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.
If you pretend more you can pay and use AWS or some other service.
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.
Also the download files themselves can be hosted on Github repos as releases which supports TLS.
