[carussell]

Let's Encrypt can still be pretty convoluted and is not headache-free, even using the officially anointed tools.

Despite your comment and the (well-intentioned) plans from browser vendors to do what they can to squash unencrypted HTTP, failure to use HTTPS, even with Let's Encrypt, is still a totally forgivable sin today.

[dewey]

I disagree, by just running https://caddyserver.com/ you would automatically have a https site up in seconds and it can be used as a reverse proxy too.

With nginx:

- `certbot certonly`

- press `2`

- type in your domain name

- press return, done

Add a few lines to your nginx config, done.

``` ssl_certificate /etc/letsencrypt/live/<yourdomain>/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/<yourdomain>/privkey.pem; ssl on; ```

[carussell]

Just to confirm, do you think "swap out your webserver for something else" is a reasonable demand?

> `certbot certonly`

You make an assumption that this is going to work with no hiccups, across all environments. Spoiler: it doesn't. I specifically alluded to certbot and certbot-auto being (surprisingly) rough around the edges.

[dewey]

I'm not demanding anything, I'm just listing some options and emailed the OP to offer my help.

[carussell]

Look, you entered a conversation where the context was that there is "no excuse" not to be using TLS today. To agree means to place demands on the people operating the endpoints where HTTPS is not yet rolled out. Your response was that these operators can "just run" their websites with TLS by swapping out their backend. You either agree that's a reasonable demand, or you don't.

Now, it is possible that you don't agree with that specific demand, and that something that involves switching the backend is merely one viable option—it's sufficient and not necessary to achieve that goal. And that's fine. But as someone who showed up to throw in their support for the claim that it's inexcusable not to be using TLS today, then the burden reverts back to you to justify the claim.

So, I ask you, as someone on record as disagreeing that it's still forgivable to be running an HTTP-only site in 2017: what are, as you see it, the minimum reasonable demands to be placed on someone operating a website?

[dewey]

I'm not sure why you even want to discuss the details of my simple suggestion or "demand" at length like that...

But to answer your question: I think if you are running a message board / forum for people to discuss various topics in general you should try to keep your users as safe as possible within your means. That means https, no plain text passwords in the database - basic stuff really.

PS: The DNS on your website as linked in the profile isn't set. Only the www. subdomain works.

[carussell]

> I think if you are running a message board[...]

Are we talking about the suitability of operating any unencrypted endpoint without TLS, or are we limiting ourselves to message boards? If the latter, does that mean there are forgivable reasons to run HTTP-only applications that aren't message boards?

> The DNS on your website as linked in the profile isn't set

DNS is set up, it just doesn't have an A record or CNAME for the bare (second level) domain. That's intentional.

> Only the www. subdomain works

The other subdomains are certainly working.

> I'm not sure why you even want to discuss the details of my simple suggestion or "demand" at length like that

Because in response to this:

> failure to use HTTPS[...] is still a totally forgivable sin today

You said this:

> I disagree

[pmarreck]

yeah but that's a webserver almost no one has heard of and may not even be in a position to switch to

[dewey]

I'd say it's pretty well known if you have anything to do with Go but there's a simple tutorial for most web servers. If you are able to build a site like that, editing some web server configs by following a tutorial shouldn't be a problem.

In any case, I like the project but I think that in 2017 it's irresponsible to do logins and user registration over http - even if it's just a weekend project.