Include Let's Encrypt

[buro9]

At the moment we need a cert, we should autogenerate and renew these.

This means something like certbot and Let's Encrypt.

Note: This is a multi-tenant system, and it needs to work with multiple tenants, i.e. different forums some of which have their own domain CNAME'd to us.

[cyclotron3k]

Would this be an optional thing? Because often you want something external to handle TLS/SSL, like your firewall or load balancer. Also, when in a development environment you wouldn't want SSL forced.

It'll also cause issues in a containerised environment where you can't bake the certs into a image, and you can't let the container request new certs every time it boots.

[buro9]

Why a firewall or load balancer? Because of TLS1.3?

At the moment running with certs is costing GBP 400 per year and multiple periods of maintenance when the certs need refreshing.

Certs required:

• Wildcard for *.microco.sm (or whatever the top domain is) for serving the API.
• Domain specific certs for the frontend of any site, i.e. www.lfgss.com .

Even if you CNAME the frontend to the backend and use something like Cloudflare to get certs for free on the frontend, you still need a wildcard for the backend.

And if you want freedom not to be fixed into a relationship with a Cloud provider, i.e. if you want to host on Digital Ocean, Linode, etc... then you need to do all the certs yourself.

From a perspective of running it... I can't see a reason not to have Let's Encrypt do all of this by default.

Only from a perspective of a development environment do I think there's an argument that it should be configurable and a self-signed cert should be possible. But the default should be zero config and fully automatic, i.e. Let's Encrypt.

[cyclotron3k]

Yeah, let's encrypt is great. I'm just saying there are scenarios where you'd want SSL termination handled by something external (or have no encryption layer at all, e.g. in a dev env).

I'm just asking if there's going to be a simple way to run microcosm without SSL, or if it will always expect to be running over HTTPS?

[buro9]

But that doesn't even make sense.

• SecureCookie need HTTPS to work (you wouldn't be able to sign in on a non-HTTPS dev environment).
• CSRF need HTTPS to work (you wouldn't be able to POST anything in a non-HTTPS dev environment.
• Latest HTTP protocols, both HTTP/2 and HTTP/3 need HTTPS to work (you'd be building in a dev environment in a way that is alien to the prod environment - stats for last 12h shows 1M HTTP/2 requests to barely 1K HTTP/1 requests, and all of the HTTP/1 requests were malicious bots).
• The client will only ever run in HTTPS to allow it to function at all.
• The API will only ever need HTTPS to work (because it's the only way to prevent credential leakage and protect the access tokens).

Whatever a dev environment looks like, it MUST have TLS enabled.

There isn't a question of whether that is a choice... the only choices are whether to allow custom certs or not. I think the answer to that is yes as self-signed, origin-ca, and custom certs are all good. But I think the default in prod should be zero config, ease-of-use and ease-of-operations... that Let's Encrypt should just handle it.

The principle I'm going for is that this new version is able to be run by those who are not technical. So they should never have to think about certs, and yet it should be secure by default. i.e. it should be maximally secure with zero config.

[cyclotron3k]

I think I've wasted enough of your time, and my time, and you've answered my question - HTTPS it is! But for what it's worth:

Secure cookie doesn't require HTTPS, just set Secure: false which will allow the cookies to be sent over HTTP (besides, they are already encrypted, or signed at least).

You're right that CSRF uses secure cookies by default, but that can be disabled. From their documentation:

// Add the middleware to your router by wrapping it.
http.ListenAndServe(":8000",
    csrf.Protect([]byte("32-byte-long-auth-key"))(r))
// PS: Don't forget to pass csrf.Secure(false) if you're developing locally
// over plain HTTP (just don't leave it on in production).

Your point about HTTP/2, mandating HTTPS... I'd forgotten about that. For some reason I thought Chrome and Firefox had made an exception for localhost but it looks like I was wrong. net/http of course supports HTTP/1, so it looks like it would be fairly simple to run without encryption, in a dev environment at least. At this point though, it looks like it would be more effort than just setting up self-signed certs.