Custom domains would be huge for me, but I totally understand. How would they ever manage to do it? They'd either need a zillion separate entries, or the broadest wildcard cert ever.
I just set up HTTPS in ten minutes using a free cloudflare account and github pages with my custom domain. You do kind of add the middleman of Cloudflare, but I'm totally okay with that.
It's like GitHub pages on steroids and includes free Let's Encrypt based SSL for custom domains, can run builds from your GitHub repo with any static site generator, supports rewrite/redirect rules/proxying/form processing/password protection and much more...
What sort of price would you consider good for static site hosting? GitHub provide theirs for free as it's a loss-leader, where as this is ther main business.
DO isn't in the same market as this, at least going off their websites. DO means doing all the work yourself. Netlify handles everything.
I don't think the pricing is too high. If anything, the high end is too low. It's not like they're aiming at personal sites, are they? And for a company, $39 is nothing -- plans should probably start there. (Seriously, who wants to service a customer for $7 a month?)
FWIW I've never seen or heard of Netlify before in my life.
You raise an interesting point. The prices seem too high for some commenters. They are presumably capable of doing this themselves on a DO box so they do not think it is valuable enough to justify that price.
However, one of the features of their highest price ($39/month) plan is that you can use 100 custom domains. If you have 100 domains hosted on Route 53 you will be paying over $50/month for domains, at which point $39/month for the service which actually hosts your static site is entirely negligible. I am curious how many people fall in to that bucket though - it seems more likely that people will run multiple sites with few custom domains, rather than a single site with 100 custom domains.
I am planning to offer some of Netlify's services in a product I am currently building. I'm still working on the pricing model but it is likely to be based on builds per month and bandwidth/storage, rather than the actual number of sites. My cost driver is not 'how many domain names are configured in my HTTP-routing layer', but rather 'how much pressure is each site putting on my build and web servers'.
Netlify never misses an opportunity to self-promote in these SSG related threads, but AWS S3/Cloudfront/route53 is so cheap and simple for the audience that would even understand the point of Netlify, it's difficult to understand their target market. Netlify is priced like Squarespace, Wix, Weebly, etc. which are quite a bit simpler.
The fact that I can click on their homepage and drag-n-drop a site folder and have it just work is pretty damn slick. $39 is nothing if you don't have to deal with stuff. The absolute cheapest guys I work with are at least $50/hr. So if it saves an hour here and there it's worth it. And more likely, you'll spend 3-4 figures in time if there's any sort of hiccup in your AWS setup.
I don't think people are thinking how nice it is to have someone take care of stuff for you, totally. If there's any sort of issue, one email, and you're done. And people aren't thinking how tiny $39 is.
Again, I've never heard of Netlify before, but the product sounds great. HN is just messed up on pricing because they're looking at AWS costs instead of customer value.
I think HN also devalues their own time: I've been running webservers since the 90s, so I know it's "easy" to do, yet it's one more thing to have to think about. Although I suppose some might enjoy it.
I think they could be much improved by allowing all the features to be modified with sliders and checkboxes with the Free/Advanced/Pro presented as presets.
Does that actually work? I know it's appealing to tech types, but it's confusing to people in general. They probably are better off going unlimited on a few things if they can. People are incredibly weird about usage-based pricing.
Plus it creates barriers by giving people something to bikeshed over before buying. In fact, I'd wager they're probably better off going to Unlimited on a few more things where they can, and only really focusing on the things that separate high paying customers from smaller ones.
They are advertising in a thread about GitHub pages. I'd expect private pages/unpaid open-source projects are the vast majority of users of GitHub pages.
Plus a lot of headaches of maintaining a machine and an OS running on that machine that cost you if you value your time. Static sites + platform = stateless.
I'd compare this service to CDNs + HTTP Object storage combos like CloudFront+S3. (Still makes this look expensive since those cost cents/GB)
Same. It took me all of ten minutes to do, with a free account. Now, if I were running some service or a huge site, I'd probably want https setup on the server side and not just use Cloudflare as an inbetween. But for a personal blog it does everything I need it to do, with zero hassle.
That doesn't actually create a properly encrypted connection. It only encrypts between the user and the site (at CloudFlare), not between the site and Github. Without that last hop being encrypted, you have to weigh whether this is an improvement or not.
It significantly decreases the attack surface, since most of the connection will be encrypted inside CloudFare's network or over HTTPs. Should be a clear win for most cases.
You can now actually use CloudFlare to issue a custom certificate for your origin server that it will accept (CloudFlare Origin CA), but of course GitHub pages won't support installing it.
Yes it does - this is all a setting you can choose and since Github does support HTTPS (and has for a while) you can always set it on "strict" and ensure a continuous encrypted connection on both sides of CloudFlare.
But what certificate will Github present for your custom domain? I don't think you can tell CF to accept Github pages's cert for your own domain. They either use their own CA or don't do auth, right? At least on non-enterprise plans.
This is where the breakdown is. Cloudflare will get the certificate for *.github.io, however it is making the request for the custom domain. It is unable to validate the certificate.
It is impossible to enable "strict" SSL mode, because it cannot validate the certificate. And as such, a bad if able to trick cloudflare to resolve username.github.io to themselves could use any SSL certificate they choose.
This is admittedly an edge case, but in such an event, the end user would see a trusted certificate and be proxied to a bad site.
You're right - the request to the origin will be encrypted but not fully validated since the host header will be different. It's still an encrypted connection though which is what the OP was asking about.
How do you do that in CloudFlare? I didn't know you could change the host in non-enterprise versions. All I've seen is the ability to proxy request to a specific IP or CNAME.
If you CNAME your site to foo.github.com, it doesn't change the R-URI or Host header.
That article doesn't address what I said at all. That's showing how to disable encryption on the backend (CF to Github) by selecting "Flexible".
Looking at CF's help again and having used them a bit, there seems to be no way at all to enable full encryption (user-CF-github) with CF's non-enterprise offerings. This is because the request from CF to Github is still requested with your domain name (TLS and host header).
In order for it to work with Github's *.github.io cert, Cloudflare would need to offer an option to rewrite the request itself, not just proxy it.
You're right that the host header wouldn't match but Cloudflare has an option to enable SSL to origin without checking for completely validated certificate. They call this Full rather than Strict: https://www.cloudflare.com/a/static/images/ssl/ssl.png
So you can still get an encrypted connection without a verified certificate.
>encrypted connection without a verified certificate
Encryption doesn't work very well without authentication. In most cases any attacker with access to the medium has read+write. And without auth, you only need to, say, change DNS to insert yourself.
Opportunistic encryption is really just a last-line defence against dragnet type surveillance. Which is good, but it's hardly having end-to-end.
Frequently changing pk enc key to setup tls connections with different certs can have a performance impact too. Let alone security implications of managing someone else's private keys.
In some cases it doesn't even connect with TLS due to some connection issue with GitHub / fastly and you need to set it to flexible (no encryption). I wonder if this new forced HTTPS redirect will change/break that?
I haven't quite worked out the rules yet but some GH pages allow full TLS on CF (but not strict cert validation obviously) and some require flexible. I think org pages need flexible (plain HTTP) but project ones support HTTPS (if on a subdomain)?
This update may change all that so will need to experiment again. If it does break things then any new sites after the 15th may not be able to be made to work. If using a CF page rule or HSTS headers to permanently redirect to HTTPS then this could be a problem.
We're working on a static site hosting service called PubStorm (https://www.pubstorm.com) that allows SSL on custom domains. It's free; we're also working on some powerful features that will set it apart from gh-pages.
Do you have any idea how TLS actually works? If this worked out of the box for custom domains, then GitHub would need to be able to impersonate those domains.
At the very least you'd need a way to upload a private key/cert combo that they could server in response to an SNI request. Given the sheer number of sites that they host (every user effectively has a custom GitHub pages page) that's not really feasible though. Hence only support for *.github.io as that only requires a single wildcard cert.
> Do you have any idea how TLS actually works? If this worked out of the box for custom domains, then GitHub would need to be able to impersonate those domains.
If you redirect your domain to my webserver, I can get a certificate for it. E.g. from Let's Encrypt.
Wordpress.com uses that and offers SSL certificates to "million-plus"[0] blogs with custom domains. It's certainly doable at scale, although I totally understand it not having priority for GitHub (esp if it doesn't fit their current technical setup).
It would just request LetsEncrypt to generate those certs and then prove the "ownership" (more like "control") of those domains by whatever method LetsEncrypt wants (.well-known perhaps?).
ICYI, you can also get free, self-renewing, wildcard SSL certs for custom domains on Bitbucket by using the Aerobatic add-on for Bitbucket. [https://www.aerobatic.com]
I just noticed it this morning when trying to put up a demo file for a project. I was confused by the docs saying 'don't do anything sensitive because no HTTPS', but clearly seeing the https:// URLs.
Cloudflare wouldn't be e2e in the sense that the SSL would terminate at Cloudflare, which would then open a new SSL connection to GitHub. Everything would be properly encrypted, but Cloudflare would indeed have access to the plaintext (i.e. it isn't e2e).
This isn't necessarily true. For example when you want to direct example.com to example.github.io Akami (serving for Github) will serve the certificate for *.github.io. Because this certificate is obviously invalid for the request you have to disable certificate validation in Cloudflare.
So client to Cloudflare is well protected but Cloudflare to Akami is vulnerable to MITM.
(And according to this new news Akami to Github is properly protected now)
You're right. And it's a shame, because they're so close.
CloudFlare appears to support this, but they actually don't. What they disingenuously call "Full SSL" is just "there has to be any SSL certificate, but we don't event check with a CA." It's completely MITM sensitive.
The only level higher than that is "Full SSL (strict)", which immediately requires a cert valid for the request host available on the origin, as you mention.
Ideally, they'd have an option in between: "Fuller SSL" (or just stop lying about their current options). Require a valid SSL certificate on the origin, for the origin, not for the request host. This way Cloudflare would ask Akamai for the *.github.io cert, and the browser would ask CloudFlare for the custom domain cert.
Let's Encrypt is a certificate authority and provides certificates and so it would be end-to-end. However, CloudFlare is not end-to-end unless the server already supports HTTPS.
I "cheated" the system by having a script that will redirect you to the HTTPS version if you click on anything from the HTTP protocol, which kind of accomplishes forcing the HTTPS encryption, but not really.
Then I've decided to switch to my own domain and just use CloudFlare (+ whitelisting Tor).
Now I'm kind of thinking about switching to GitLab Pages since they pretty much kick the hell out of GitHub Pages in every single way when you compare their features (like, you can use any static site generator and you can roll your own Lets Encrypt SSL certificate on them).
To clarify, you mean you can if you add the output to your git repo right? Currently I have gh pages set to automatically build my site with jekyll, but I believe they limit plugins to only safe ones.
It's a feature they introduced pretty recently (~ a month ago IIRC), but it always kind of worked with CI + some tinkering (I know this because my organization used our own instance of GitLab as our publishing platform before this feature became a thing).
I've been running the HTTPS Everywhere add-on and hadn't realised that this wasn't already a thing. As the post says, they have supported HTTPS for a while and this is just adding a redirection option so you don't need to resort to JS hacks. It doesn't say if they are using 301 redirects or HSTS headers, I'm guessing the former.
You have been able to request Pages sites over HTTPS for some time, but we refrained from officially supporting it because the traffic from our CDN to our servers wasn't encrypted until now.
If I understand it correctly, the same HTTPS certificate is used for all GitHub pages websites. So hypothetically, I could do a MITM attack and redirect a user from an HTTPS protected GitHub pages site to my malicious GitHub Pages site right? (although the url would be different... but could be similar)
You don't have access to their private key. The fact that it is the same certificate is irrelevant. Anything you can do now, you could also do if they'd use separate certificates per subdomain.
