Use HTTPS only

[C0rn3j]

Perhaps only enable TLS 1.2.

Having a HTTP website for a distribution shows that the people behind it don't care for security too much.

https://bedrocklinux.org/

Let's Ecrypt certificates are free, the tool to get them is certbot and you can automate getting them via cron.

[paradigm]

There was a discussion about it on reddit here, which may be of interest.

While the need HTTPS on Bedrock Linux's website is arguably much less than many other websites - no credentials, no cookies, no javascript, and all the project's code is delivered via HTTPS via github - it's still quite important.

Previously I had wanted to wait until Let's Encrypt was out of beta, which it appears to now be.

My plan going forward is to first finish the upcoming release's code. After that I normally spend some time actively running the code on my machine to test it ("dogfooding"). During this period normally allocated Bedrock Linux development time is freed up and the focus goes to updating the project's website's documentation for the next release. I plan on figuring out Let's Encrypt or some other HTTPS solution then.

It's definitely worth having an open issue on this.

[C0rn3j]

From my own notes - https://c0rn3j.com/index.php?title=System_administration#Let.27s_Encrypt

There's really nothing about figuring out Let's encrypt, it's stupid easy and would likely take you max 20 minutes to implement an automated solution.

I use Nginx as the webserver and configuring it is extremely easy too.

Thanks for caring about moving to HTTPS!

[paradigm]

I appreciate the notes. The project's website is also on nginx, so that'll correspond nicely.

My concern isn't the time to do an initial setup - which can happen whenever - so much as the time to debug what goes wrong if I somehow mess it up, which then becomes a priority as the user-facing website may be down or broken. Despite knowing I'm almost certainly being overly cautious here, the desire to make sure I don't tackle this without sufficient time alloted remains.

If I have a relatively open weekend I might try to knock it out some Saturday morning where I have the rest of the weekend to fix it if things go wrong. This immediate weekend isn't good, but maybe an upcoming one will be. I'll make the next release a firm deadline, but try to get it done before then if possible.

[C0rn3j]

Just do nginx -t before doing nginx -s reload, that way you're sure you didn't screw something up.

But I assume you know that already

[paradigm]

You're correct, that was trivial. nginx -t helped ease concerns. Mind double checking everything looks good from your end?

[C0rn3j]

There's one misconfiguration, you need to generate your own DH key.

https://www.ssllabs.com/ssltest/analyze.html?d=bedrocklinux.org

https://c0rn3j.com/index.php?title=System_administration#TLS.28used_to_be_SSL.29 < - the dhparam command

Keep in mind that only enabling TLS 1.2 will block some extremely outdated clients from accessing the page, since they're not even aware 1.2 exists. (IE in Win XP and the like, you can look on the ssllabs page I posted).

EDIT: As a bonus, you can set a HSTS header (basically a header that says "hey, this site ONLY supports HTTPS, don't even try connecting via HTTP), and you can then enter a HSTS preload list which will basically mean that all major browsers will bake your website in their HSTS list at compile time, and future browsers won't ever try connecting via HTTP on the site(with HSTS header they have to connect at least once to be aware of the header) and ALL the subdomains.

Using HSTS can be a problem if you have a subdomain that relies on HTTP.

EDIT2: Actually nginx supports TLS 1.3 since 1.13.0. You could enable that too. (but definitely not as the only option as TLS 1.3 is still not officially completely out and next to nothing supports it I imagine)

[paradigm]

I generated my own DH key, as well as applied other tweaks I learned about via the resources to which you've directed me (very, very useful - thank you!).

The remaining open items are:

• DNS CAA (which I believe I've resolved but will take time to propagate).
• HSTS preload (which is rightfully upset at the www subdomain for which I do not have a cert. Rather than getting one, I'm removing the subdomain, which again will take time to propagate).

EDIT: The website is running on Debian Stretch which has nginx 1.10.3 which lacks support for TLS 1.3. Moreover, it looks like TLS 1.3 is still in draft? I'll make a note to look into enabling it (as well as revisiting ssllabs.com and other sources to see if any other changes should be applied, such as new ciphers) on a semi-regular basis, but I'll leave it disabled for now.

[C0rn3j]

Just read about DNS CAA - looks like most major DNS providers don't support it (mine doesn't - looking at you Namecheap) https://www.ssllabs.com/ssltest/analyze.html?d=bedrocklinux.org

As for the HSTS preload, I'd just add the www subdomain. After all the cert is free. Some tools (observatory) will tell you to add it, as some people just add www before the domain name since they're used to it.

also FYI - LE will have wildcard certs starting Jan 2018.

[paradigm]

Added the www subdomain and submitted for HSTS preload. Only thing remaining I'd like is DNS CAA. Provided you don't see anything else, once I've got DNS CAA looking good I plan on closing the issue.

Sad to hear Namecheap and others don't let you use DNS CAA - it looks like quite a good idea.

[paradigm]

Both ssllabs and dig bedrocklinux.org CAA are still reporting DNS CAA has not been set despite plenty of time for the DNS information to propagate. It appears DNS providers like Namecheap don't support CAA because it's so new. I wouldn't be surprised if my attempt to get it configured with my current DNS provider is not working because it is so new. I consider this out of the scope of this issue, but I'll revisit it after DNS CAA has had time to become established.

Feel free to comment or re-open if you think there's more to be done here. And thanks both for pushing me to do this as well as helping me get it done correctly.

[C0rn3j]

CAs have to respect CAA records starting September 2017, so you may check if your DNS provider supports it by then.

thanks both for pushing me to do this as well as helping me get it done correctly.

No problem, happy to help!

[C0rn3j]

Oh just one more thing that you should watch out - since the certs are 90 days only, you should make sure the automation actually works.

Certbot has a dry run option if you want to test the automation.

Personally I've set an fcronjob for a simple script 30 12 1 /bin/bash /home/c0rn3j/C0rn3j/certrenew.sh &> /home/c0rn3j/certrenewlog.txt

https://gitlab.com/C0rn3j/C0rn3j/blob/master/certrenew.sh

EDIT: My scripts are now located in this repo if someone wants to take a look - https://gitlab.com/C0rn3j/configs

[paradigm]

Asking certbot to do a dry run of the renewal process looks good. I made a note to double check everything again as the renew date gets closer.

[paradigm]

The advice to double check was a good one.

It looks like my cron job renewed the cert on disk. However, it did not tell nginx to use the new cert, which means the website would have used an expired cert. I've updated the cron job accordingly.

Also, it appears letsencrypt sanity these things - it sent me an e-mail letting me know that, from their point of view, it looked like the cert was going to expire. Major props to letsencrypt for making the process and painless and fault resistance as possible.

[C0rn3j]

I think you get the email warning either way. But yeah, it's nice that they do so by default! :D