Please petition GitHub to support HTTPS on GitHub pages(gist.github.com) |
Please petition GitHub to support HTTPS on GitHub pages(gist.github.com) |
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.
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
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?
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.
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).
(Disclaimer: That said, I haven't seriously assessed the scalability of typical ACME clients. I would appreciate any hard number for them.)
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.