Switching Your Site to HTTPS on a Shoestring Budget | Hacker News Reader

Switching Your Site to HTTPS on a Shoestring Budget

css-tricks.com

69 pointsrobin_reala60 comments

Is this meant to be camouflaged advertising for Cloudflare?

Why don't they mention Let's Encrypt? It is free and easy to setup.

Probably because the author was hosting on Github Pages, and you don't get to set your own certs.

In that case, they could at least explain why Let's Encrypt was no option for them. Doing that in a half sentence would have been sufficient. But they don't mention Let's Encrypt with a single word, nor any other alternative.

Both GitLab Pages and Netlify has LE support.

Let's Encrypt rocks!

FYI there is an alternative to Github Pages + Cloudflare if you want to use Let's Encrypt using the same features of Github Pages: Gitlab Pages. It allows you to add your own certificates with the only downside that there is no good option to enforce HTTPS (only workarounds, at least for now; there is a discussion on the matter [1]), if this is a problem for you the solution is (Github|Gitlab|Bitbucket)+Netlify, which, personally, I find to be perfect.

[1] https://gitlab.com/gitlab-org/gitlab-ce/issues/28857

> the only downside [is] that there is no good option to enforce HTTPS

You also have to use GitLab.

I much prefer GitLab to GitHub.

Besides aversion to any particular vendor in general, is there a reason you wouldn't want to use them?

I maintain a couple open source projects on Github that belong to the US Government. Getting them open sourced at all was hard enough. Convincing the powers that be to let me use Gitlab isn't practical.

That's very interesting! I wonder if there's anyone at GitLab interested in becoming an approved vendor for the US government/DOD. I also wonder if the code.mil people are interested in getting the ball rolling on that from their end.

Open source means the project can be redistributed by any user. So any user, including yourself, can re-host the project on Gitlab.

Couldn't you just fork it yourself on gitlab? Or any random person fork it?

I assume the intersection of projects that need a no-budget solution for hosting an https site and projects that belong to the US government is zero.

Am I missing something?

I mean, yes, if you have practical problems that make gitlab harder to use, don't use it. No problem at all. But it is still a perfectly valid solution for the problem the GP was trying to solve.

Only for Pages, though. (Disclaimer: I haven't actually tried the following setup myself, since I run my own server.) GitLab supports repository mirroring, so you can keep using GitHub for everything else. When you push code to GitHub, it will be automatically pulled into GitLab and trigger the CI job for Pages, generating and publishing the site.

This is where Cloudflare comes in.

This is where you lose control over your website:

https://blog.cloudflare.com/why-we-terminated-daily-stormer/

Cloudflare is a dns provider, not a register. You can switch your dns in under 24 hours if there is any issue with them.

I mean, if you intend to kick up enough of a shitstorm to be the only person ever denied service by Cloudflare and then be denied service by Godaddy and Google domains, then I guess this rings true?

For everyone else, I'm thinking the few hours it takes your DNS settings to propagate in the unlikely event you'll even have to is probably a reasonable tradeoff for free.

> be the only person ever denied service by Cloudflare

...so far

http://www.washingtontimes.com/news/2017/aug/30/cloudflare-p...

this has only just begun

It will be interesting to see where that goes in terms of codifying universal standards. "Existing on a list of 'terrorists' managed by certain nation states" is probably too politically biased. Case in point, the U.N. has passed many resolutions condemning Israel's aggression and violence against civilians. Also you could argue the U.S. drone assassination program induces terror in populations, just as China flying killer drones over San Francisco would to us. Even if they only meant to target, say, violent Neo-Nazis. The lack of fair trial, the collateral damage, the hum of the ever-present drones, the idea that you could be wiped out on the street at any moment.. it's terrifying.

If tech companies want to wade into this they would need to codify a standard that applies universally to all violent political actors. And, guess what, this comes up a lot in the U.N. and the militarily powerful nations tend to shy away from anything that might include what they do as "terrorism" or illegal. They tend to prefer blacklists they manage themselves over universal standards.

Get SSL from using a thirdparty MITM?

Not only do they control your DNS they also control all traffic going to your site, also the connection between you and them is not encrypted.

I figured this would be a tutorial for letsencrypt. Cloudflare certainly is an option but it's not one I would recommend for -most- people unless I know why they're opting for SSL. If it's static content then sure- but I don't support cloudflare for dynamic content. I'm responsible for things like passwords and I can't keep that responsibility if I actually choose to MITM my own site with an external company.

Trust doesn't enter into it. I don't trust myself with your password so why would I trust anyone else?

> also the connection between you and them is not encrypted.

The tutorial uses the Full encryption option, which does encrypt the data between your origin server and Cloudflare. You might be thinking of their flexible SSL option?

[EDIT] I might add that for anyone not using GitHub Pages as per the tutorial, they'll need additional steps to get Full SSL working with Cloudflare. It's not effortless.

The problem is CloudFlare offers zero way for an end user to identify if a site is setup with flexible SSL or not. Therefore I have no way of verifying the full path back to the origin.

I brought this up and was told "This is something we are definitely considering." but heard nothing beyond that.

they won't do it as it's one of their major selling points: one click ssl

by offering the "flexible ssl" option at all it seems that they couldn't give a toss whether on not it actually protects anyone

Playing Devil's advocate: when you run your site on any provider, except maybe colo'ing, you're also giving them access to that data, as they could peek into the system's memory . Using Cloudflare is just adding a second provider.

Sure, but Google or AWS looking at your specific certs and using them to decrypt your traffic or impersonate you is probably far less likely than someone MITMing Cloudflare's connection to your server or even worse finding a vulnerability in CF (see cloudbleed [1]). I really really dislike how Cloudflare has legitimized MITMing many sites while making it look 'secure'. It's basic security, never trust someone else with your keys.

1: https://en.m.wikipedia.org/wiki/Cloudbleed

> Using Cloudflare is just adding a second provider.

Thus immediately increasing risk by 100%.

In actuality though, even more - if you use the setup where the connection between you and CF is not encrypted. In that case any hop along the way between you and CF could intercept the data.

> Also the connection between you and them is not encrypted

While you are right in that cloudflare won't stop you making this questionable design choice if you want, you shouldn't and you don't have to either.

You can still use cloudflare's ssl certificate AND use letsencrypt/<other cert provider> to secure traffic between cloudflare and your server, ensuring SSL end to end (aside from the obvious MITM stuff cloudflare have to do in order to successfully retrieve content from their caches etc). Cloudflare call this configuration "full" encryption, as opposed to the somewhat terribly named "dynamic" setup you are referring to.

This is one aspect of cloudflare I'm not huge on either, given that when users see an SSL padlock they may have a reasonable expectation their input is at least encrypted until it reaches the destination server (again with the cache MITM caveats and so on) but no one is forcing you to use it that way.

If anyone is interested in a Let's Encrypt solution but doesn't feel like spending a ton of time figuring it all out, I recently released a course[0] that covers this topic in great detail.

The TL;DR is it goes over the entire process of setting up a new server, buying / configuring a domain name and securing your site with Let's Encrypt in an automated way.

Production ready configs are included to support nginx and Apache running on Ubuntu or CentOS. It will work with any web framework or static site.

[0]: https://httpswithletsencrypt.com/

OK, but... if you don't already have a server and a domain name set up, why are you looking for a course on Let's Encrypt? Wouldn't the more appropriate use case be to list out the most common server setups, and instruct how to add Let's Encrypt to existing setup?

Of course, when I was setting it up, Googling gave me pretty clear instructions, so a course wasn't needed, but depending on the exact server setup people have, maybe some installs are harder than others...

Hi,

Most of the course is going over a bunch of common server set ups (1 static site, multiple sites on the same server, reverse proxies) along with going over how Let's Encrypt works and how you can apply it to nginx / Apache.

About 20 minutes out of the 3 hours of content is dedicated to registering a domain name and setting up the server itself.

I added those sections because it makes the course an end to end solution on how to go from "hey, I have my site on my own computer but how the heck do I securely host it on the internet?" to really doing it.

That decision was guided by feedback from existing people who have contacted me and asked for that information specifically.

Lots of people have applied the course's content to their existing set up. That's how most people ended up following along.

> Wouldn't the more appropriate use case be to list out the most common server setups, and instruct how to add Let's Encrypt to existing setup?

I think the EFF already got that covered: https://certbot.eff.org

certbot works, but I'm not a fan of using it.

I'd much rather configure nginx / Apache myself so I know exactly what's happening and can mold the solution to fit whatever use cases I have.

certbot --standalone

You'll need to turn off your web server for a minute or two while certbot runs ('standalone' means it starts up a temporary web server of its own and binds to port 80 for a moment) but then it leaves the new certificate for you in a few files in /usr/local/ somewhere, and you proceed to edit the nginix.conf file yourself. It works great.

You don't need to turn off your webserver, you can use `certbot certonly --webroot -w /path/to/docroot ...` where /path/to/docroot points to the document root, i.e. the root directory of the website contents, provided that your webserver is listening on port 80 (HTTP).

On my personal servers, I have the regular webserver configured to listen on port 443 (HTTPS) only, and I have a separate webserver on port 80 that's only used for ACME challenges. All other HTTP requests are immediately upgraded to HTTPS. Among other things, this split solves the cyclic dependency between the webserver not starting without TLS certificates, but also being required to provision certificates.

Details: https://blog.bethselamin.de/posts/how-i-run-certbot.html

You can also use the dns challenge and not worrying for the web server at all.

Cloudflare is a valid suggestion, albeit (IMO) inferior to letsencrypt in many cases. Surprised to not see it mentioned here, given that it also costs nothing, for arguably more security.

LE doesn't work here. As the fine article points out, GitHub Pages does not support TLS on custom domains. With CF, this works.

For the sort of thing that you'd host on GHP, this is totally fine in my opinion. In fact, because CF is a pretty good CDN it likely accelerates page load times considerably for Non-Americans.

(I wish it'd be possible to do something similar for readthedocs, which only has one origin and it's located in North America, but alas this doesn't really work).

Yep, the article is a great example of why one would use CF over LE. I think LE is worth an honorable mention given the topic, but it's not a big deal.

A better title would be "Serving a GitHub page on HTTPS...".

This is far from a proper and secure setup. The whole point of TLS is to ensure users are talking to you and not someone else while protecting the data. This accomplishes neither.

Welcome to the new world, where https only purpose is to prevent the browser from telling visitors your site is not secure.

What's the problem? You have to trust Cloudflare, but that's no different from having to trust GitHub. Cloudflare's "Flexible SSL" option does have the problem that the connection between Cloudflare and GitHub is not secure, but this tutorial doesn't recommend that; instead, it recommends a setup wherein Cloudflare validates the *.github.io certificate, so the full path is authenticated.

The problem about the free Cloudflare SSL certificate is that you share it with a lot of other sites, most of then with "strange" purposes...

This is a common concern, but in reality, it does not mean anything. "Sharing" your cert with a weird site is similar as taking the same bus route as someone who is bad.

From a security standpoint, there is little to no risk. Worst case scenario one of the other sites is doing something that results in the cert being revoked... and I imagine CloudFlare has a way to just move you (and everyone else) onto another cert seamlessly.

I dunno, it _mostly_ doesn't mean anything, but the day I discovered my site hostname listed next to phishing and porn sites was the day I didn't want to use CloudFlare's free certs anymore. Sure not many people will see the SANs on a cert, and there's nothing wrong with porn using SSL, I just don't want to cobrand with them. :D

So pay for the package that doesn't do that

That would be silly since I now run a competitor — with a free tier that doesn't do that. :D

Hah. I really should read usernames before responding.

I actually know of your competitor (fly.io, right?) and am giving it a test for something I'm working on that needs the hostname support after Cloudflare got me legging it when they said their hostname system was for the Enterprise plan.

That's it! How funny. Send me an email and let me know how it goes: kurt@fly.io

Here's how I did this on a WordPress on Apache, terminated at the Apache:

https://rocknerd.co.uk/2016/12/04/rocknerd-is-now-fully-ssl-...

It took ten minutes. I boggled at how easy it was.

I don't think you can get away with using Cloudflare's free SSL.

I tried, and I had no real excuse when some users said it didn't work for their old browsers at work. So I paid the $20/mo which made it work in all browsers and had other features that were useful to me, like on the fly image transcoding for mobile devices.

If you're really on a shoestring budget, I have a hard time justifying shutting down legit users. Just use something else like Lets Encrypt.

The issue you ran into is not specific to Cloudflare; in particular, Let's Encrypt will not help you work around it.

The problem is that ancient (pre-2006) versions of the TLS protocol provided no way for the client to tell the server, before authenticating, which hostname it wanted to talk to. So there could be only one certificate (and therefore, in practice, no more than 100 hostnames) per IP address, which made the use of HTTPS on shared hosting impossible. If you wanted HTTPS, you had to get your own static IP, which is what costs $20 per month (and you can't get it that much cheaper anywhere else).

Server Name Indication is a newer extension to the TLS protocol which solves this problem by letting the client specify, when initiating the negotiation, which hostname it wants to talk to. So HTTPS on shared hosting is now possible...unless you need to support truly ancient clients (most notably Windows XP) that are stuck with outdated TLS implementations that don't support SNI. Considering that XP doesn't even get security fixes anymore, and pretty much all clients newer than Windows Vista support SNI now, and running software that old is really not safe (Vista doesn't get security fixes anymore either), I don't think I'd have any qualms about telling those users that they need to upgrade.

If you are deploying with Docker there's this rather simple letsencrypt setup that I literally just got working:

https://github.com/JrCs/docker-letsencrypt-nginx-proxy-compa...

Just add the environment variables for your container, and the docker compose file from [1] and you're proxying with Let Encrypt SSL support. I encountered a few gotchas so feel free to email if you get stuck.

It really does do some interesting magic but so far seems to work great!

[1] Docker compose file and nginx.tpml here: https://github.com/evertramos/docker-compose-letsencrypt-ngi...

Why not mention let's encrypt and caddy?

Until last year I had been using an SSL certificate purchased from SSLSecurity . However,I switched to AWS provided free SSL certificate for my domain, which is free and usable with my Elasatic Beanstalk applications . I have a static website hosted on AWS S3+ Cloudfront and AWS SSL certificate worked there as well.

edit : I also use letsencrypt certificates on my Linodes.

Thought I would bring up fly.io which will give you HTTPS on Github pages for free with a limited amount of traffic. It appeared on HN a few days ago.

[0] https://fly.io

[1] https://news.ycombinator.com/item?id=15135552

Wow that's complex! Route53 and AWS Certificate Manager are way easier to setup.

Simpler than just changing your name servers? If you’re not using Route 53 you’ll need to do the exact same thing anyway.

Reply on news.ycombinator.com