TLS versions and ciphers

[fredericmoulins]

Mozilla maintains a configuration recommendation for TLS:

• as a document: https://wiki.mozilla.org/Security/Server_Side_TLS;
• and as a configuration generator for the most common open source servers (including dovecot, nginx, postfix) : https://ssl-config.mozilla.org/.

Three profiles are defined: Modern (no backward compatibility), Intermediate (general purpose), Old (backward compatibilty with very old clients).

The intermediate profile consist of TLS 1.3 with all ciphers, and TLS 1.2 with a selection of ciphers. The global ciphers order is also important.

Currently, the main servers in homebox have different TLS configuration profiles:

• nginx uses TLS 1.2 (no less) with a custom selection of ciphers close to Mozilla's Old profile (many of them might not be usable with TLS 1.2);
• ejabberd uses TLS 1.2 (no less) with default ciphers;
• postfix and dovecot use TLS >=1.0 (no SSL) with default ciphers.

Would it be ok to configure the Intermediate profile for the different servers in homebox, or are there cases where more compatibility is needed (eg postfix)?

Then, as the recommendation has evolved in the past few years, it might probably evolve the same way in the years to follow. Unfortunately, those profiles are not available as cipher specs in openssl for example, and the HIGH, MEDIUM, LOW specs are far from the same criteria, so it's not possible to configure an Intermediate spec and let the openssl updates take care of the selection.

How does homebox allow to stay up to date?

Mozilla's recommendations are also maintained as JSON files with a nice warning about compatibility on updates. This could be used to at least issue an alert that the current server configuration is no longer recommended so that admins can admin, or maybe to take the risk of automatically updating the configurations.

The debian updates will happen every ~ 3 years (~ 5 years using LTS). A run of the homebox playbooks will surely occur to update or reinstall, that could be considered sufficient to get the new configuration. (Let's say that TLSv1.2 or one of its ciphers gets broken in 12 ~ 18 month, is it ok to wait for the buster+1 release in 2022 and trust the security updates mitigations if any until then?)

[fredericmoulins]

Related with a different recommendation: https://cipherli.st/.

[arodier]

I love the idea of synchronising ourselves with the Mozilla recommendations.
I love the concept of modern / intermediate / backward compatible.
I propose to use Mozilla, they have been here for a long time, and to use the same terminology.

Mozilla offers the recommendation in JSON, as static or rolling.
This will be a pleasure to implement it with this. They recommend to use version specific, which is fine, IMHO.

For instance:
https://statics.tls.security.mozilla.org/server-side-tls-conf-5.0.json

[arodier]

@fredericmoulins, I have assigned myself on this one, but I am happy if you want to do it.

[fredericmoulins]

Yes, I will try it soon. I had notes already on where and what to change.

Not sure yet which way to use the JSON definition, but will try something.

[arodier]

OK. I think there are Ansible filters to parse JSON, good luck!

[arodier]

I am going to focus on the other project, the relay vpn to provide a static IP address to those who have a dynamic one. So you have the free hands on this one. Ideally, it would be nice to have the option to automatically check the ciphers to use every month or so.
I am also testing a little bit the buster setup.

[fredericmoulins]

On the basis of #294, there are two points I would like to discuss:

• the server's cipher preferred order;
• the automatic notification of a new recommendation from Mozilla, or automatic configuration.

For the server's cipher preferred order, Mozilla currently recommends not forcing the server's order for the Intermediate profile. They got there through a long discussion : mozilla/server-side-tls#178. From what I recall, preferring the server's cipher order in this configuration does not make an significant difference security-wise, and it allows clients to choose ciphers for which they have been optimized.
It is contrary (but not without reason) to what has been advised and written on the web for years, so TLS tests will notice it, for example. Another example is the set of TLS recommendations from ANSSI, which recommends imposing the server's preferred order if the clients are not controlled.
The exact arguments from Mozilla would need to be found to see which are more relevant in the Homebox case. (As it is now in #294, the parameter is configurable.)

About the usage of the recommendation in JSON format, as they recommend, I agree with the usage of a specific version (5.0 in #294).
I am not in favor of automating the retrieval of the TLS parameters. I prefer having any revision of Homebox tied to specific parameters from the recommendation in the committed code/configuration, and not having to rely on an external call during configuration. It also allows to control the different target versions (eg Stretch and Buster, TLSv1.2 and TLSv1.3), and eventually override the recommended parameters. (That's how it is done in #294.)
I would like to have a check on the availability of a new version of the recommendation (need to explicitly add the version in the security.tls object). It could even specifically check the parameters used in Homebox.
A cron job with an email sent (no jabber) would be doable in python. But would it make more sense to have it done by a monitoring service?
There is the zabbix playbook. Monit seems interesting with its configuration language.
Using a monitoring service in the base install would also allow to check for several other aspects (reboot required, disk space, … cf Monit use cases).

What do you think?

[arodier]

I agree about taking the certificates in the HomeBox git repository.
About the monitoring, this is another story, the solution we need should be minimal.