Hacker News new | past | comments | ask | show | jobs | submit login

This is great -- it has a killer feature that I think GitHub Pages is sorely missing (unless it exists and I'm just ignorant to the fact). Custom domains WITH SSL.

Right now I have my custom domain set up on GitHub, but it's not SSL. I would love to be able to do that.




Clourfare provides free SSL - just proxy through them.


There are several problems with it:

1. the certificate is not generated by you (in the Free or the Pro plan) but by them and these certificates are for multiple domain names. So you end up sharing your certificate with other domains / websites of dubious nature that are also on CloudFlare's network.

2. CloudFlare only secures the connection between users and the CloudFlare network. It does not secure the connection between CloudFlare and your hosting service, unless your hosting service also supports TLS/SSL connections and you activate their Strict SSL option.

For the purposes of hosting a project website, secure connections are more important than ever due to the potential of external attackers, which could very well be a government institution, to infect distributed binaries or source code. Instances like XcodeGhost will become more common imho. And a secure connection between your user's browser and your hosting server is not 100% secure, but it's a good start. And towards that purpose CloudFlare Free in front of GitHub Pages isn't very good ;-)


Why is #1 an issue?


I've been wondering about this. I share mine with several shops that appear to be selling low-schedule drugs on the clearnet.

Don't know what the implications for that are, except that someone poking around the validity of my SSL certificate will establish that mine is a free tier Cloudflare one.


If a domain that you share your certificate with has their certificate revoked or is blacklisted for any reason this could have a negative impact on you.


It's a single certificate that never leaves CloudFlare's hands so revocation seems unlikely and they'd manage it for you if anything came up.


But the traffic after cloudflare's proxy is plaintext right?

I know CloudFlare has better thing to do than sniffing websites but I don't see the point of installing an SSL certification using clouflare or any other third-party which will handle traffic the way they do. You don't own the certificate, they do.


That's one option; they also offer strict SSL on both sides of the connection: https://www.cloudflare.com/ssl/


How would that work if Github pages don't support SSL?


GitHub supports SSL for *.github.io so you can have your custom domain with SSL on CloudFlare, and CloudFlare can proxy https://example.github.io/... on the other side.

eg: End User <--> https://example.com <--> CloudFlare <--> https://example.github.io


Rewriting the Host header in this way requires a non-free CloudFlare plan.


It won't. http://stackoverflow.com/a/28457335/239657

(1) Last I checked, cloudflare's "Strict SSL" mode only accepts from the backend a cert for the custom domain you're trying to serve, not accepting the github.io cert. A pity they don't let me configure what cert(s) to accept from the backend...

(2) In addition, Github have indicated their current github.io SSL is not actually end-to-end secure — it's only secure from their CDN (Fastly) but their link to the CDN is unsecure. So there is absolutely zero you can do — Cloudflare or anything else — to make GH Pages end-to-end secure on custom domains.


edit: disregard, I was wrong.

If I'm not mistaken, you have to change the DNS of the domain to something *.cloudflare.com to be able to use their service, so it won't work in this scenario.


It will. There is no need to change the nameservers of the domain for Github/Gitlab.



Just for reference—you can achieve this if you run your site behind CloudFlare. I run my own blog this way.


That's not truly end-to-end encrypted though, right? The server -> CloudFlare goes over HTTP.


When using GitHub Pages, the server -> CloudFlare goes over unauthenticated HTTPS (using the HTTPS "not strict" option), which means it is resistant to passive attackers but vulnerable to active MITM attackers.


Do you have to hand over your private keys for that?


How would you do that without handing over your private keys? Otherwise gitlab couldn't serve your site. Also, as soon as you point an A record of your domain to somebodies server, they're able to get valid certificates through acme (which is probably what they do). If you don't trust somebody, don't point your domain to them.


> How would you do that without handing over your private keys?

CloudFlare has that figured out https://www.cloudflare.com/keyless-ssl/


It depends on your goals.

If your goal is to tick a compliance box saying "no third-party has access to our private key" or "our private key never leaves our DC", then they have it figured out. If you want an additional barrier between your web server and your private key for Heartbleed-like vulnerabilities, this is also viable solution.

If your goal is to have end-to-end encryption between your server and a visitor, or hope this is going to protect you in case CloudFlare or GitLab are owned, then this isn't a real solution. CloudFlare has access to your session keys, and if they're owned, those can be logged and used to decrypt traffic. Even with a leaked private key, older sessions would be safe thanks to PFS ciphers, so Keyless SSL doesn't really change anything here.


It's entirely possible that GitLab could integrate Let's Encrypt and generate their own private keys. Some large shared hosting providers already do this (e.g. DreamHost).

Keys are cheap and plentiful, just regenerate & reissue however often you like. The paid CAs I've used do free reissues with new CSRs no problem. You are already trusting them to serve your site so adding a private TLS key isn't a big deal.

The only downside I could think of is if you are using HPKP with a long duration, you could have issues with rapidly changing keys. But I wouldn't expect GitLab Pages to support setting those headers so probably another non-issue.


We are already considering that and given past experience it is a quite simple process: https://gitlab.com/gitlab-org/gitlab-ce/issues/14926

GitLab CI Lead


You do but you would likely make a new key for this specific domain so you don't have to hand over any important keys.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: