* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
* Fix a typo in the ssl_ciphers line
I wrote !SHA1, should have written just !SHA. Very sorry about the noise.
* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
To further increase security add a strong Diffie-Hellman group, which is standard practice when setting up ssl certs. Anyone who can setup letsencrypt can also setup a DH group.
* Add cost estimate column
To give interested admin an idea of what expected costs might be.
* Add estimate for mastodon.technology
based on blog post
* Fix missing header dashes
* Add docker guide from main repo readme
* Add maintenance tasks doc to running section
* Clean up markdown in prod guide
* Move guidance to use tagged releases to docs
* Move local domain and host config to docs repo
* Title of page
* Update Production-guide.md
Intended to avoid setting duplicate HTTP headers which will cause issues with tools like Mozilla Observatory many people use to evaluate an instance's security.
Removing some of the confusion around what format S3 bucket names and regions should be entered as well as providing an example of an S3 policy that follows best security practices for this sort of thing.
Disable DHE ciphers. We don't loose any compatibility as we already use TLS 1.2, and ECDH is faster and safer.
Also, it's better so specify the curve.
This is the conf I use here : https://tls.imirhil.fr/https/mstdn.io
must be added to the Sidekiq invokation in your systemd file
The pull queue will handle link crawling, thread resolving, and OStatus
processing. Such tasks are more likely to hang for a longer time (due to
network requests) so it is more sensible to not make the "in-house" tasks
wait for them.
Heroku uses the referrer URL to point at the repo that should be deployed; from this page that includes part of a path that breaks the deployment (specifically /blob/master/docs/Running-Mastodon/Heroku-guide.md).
I've replaced the vanilla address with one that includes a specific reference to the root of the repo
work flawlessly was a nightmare). WARNING: This commit makes the web UI connect to the streaming API instead
of ActionCable like before. This means that if you are upgrading, you should set that up beforehand.
