Updated SSL/TLS defaults

[moogle19]

This updates the default SSL/TLS configurations according to Mozillas Server Side TLS Guidelines.

The last update of the configuration was in 2018 and didn't support TLS 1.3.

Since support for TLS 1.3 was added in OTP 22, I also bumped the Elixir version to 1.12 (since it was the first version requiring OTP 22).

[josevalim]

@moogle19 can you please bump CI? We can also upgrade 1.13.3 to 1.14.4.

[moogle19]

Currently honor_cipher_order is set to true (which enforces the servers cipher order) when either :strong or :compatible are set.
Mozilla recommends to let the client choose (which is also the OTP default behaviour).

Should I update that too?

[josevalim]

@moogle19 let's not change that in this PR and we could have a separate discussion for it, because I want to involved the Security WG in those changes.

[voltone]

Since support for TLS 1.3 was added in OTP 22, I also bumped the Elixir version to 1.12 (since it was the first version requiring OTP 22).

The initial implementation of TLS 1.3 in OTP 22 was incomplete and buggy. I would not enable TLS 1.3 on OTP <22.2 at all, and I would recommend at least 23.0.

So if Plug still supports 22.x, should we perhaps retain the old strong variant when the ssl application version is less than 10.0 (to be determined at runtime, not at compile time)? That's going to be a bit of a pain to document, though. The alternative would be to require at least 23.0.

Currently honor_cipher_order is set to true (which enforces the servers cipher order) when either :strong or :compatible are set.
Mozilla recommends to let the client choose (which is also the OTP default behaviour).

Mozilla's use-case is very browser-oriented. I suppose all modern browsers now send a reasonably set of ciphers in an appropriate order. For Plug/Phoenix we should consider a broader range of clients, including API clients built by people without much TLS experience.

I suppose for the strong variant we can use the client order because there is not much that can go wrong, but for the compatible variant this might lead to clients preferring DH key exchange over ECDHE, which has a negative performance impact on both client and server.

[josevalim]

We can require Elixir v1.14 but we will probably need to wait at least 6 months before releasing a new version (which is fine).

[voltone]

Ah, one more thing: the new strong configuration only supports ECDSA certificates, but I don't think that's realistic just yet: I think the majority of Plug/Phoenix deployments still uses RSA certificates. Again, Mozilla can impose stronger restrictions on their own servers because they can choose to mandate ECDSA certificates, and modern browsers support that.

[josevalim]

So is it safer to wait until the whole tooling (and web) becomes more mature? Or maybe we use the specification from 2 years ago?

[moogle19]

Ah, one more thing: the new strong configuration only supports ECDSA certificates, but I don't think that's realistic just yet: I think the majority of Plug/Phoenix deployments still uses RSA certificates. Again, Mozilla can impose stronger restrictions on their own servers because they can choose to mandate ECDSA certificates, and modern browsers support that.

Isn't the certificate only used in the CertificateVerify message? This should also support RSA certificates if I am not mistaken (In any case, I have enabled TLS 1.3 on servers with only RSA certificates).

[voltone]

TLS 1.3 will work with RSA, but the "Modern compatibility" requirements specifically require an ECDSA certificate. But actually the settings used in this PR will also work with RSA, since unlike TLS 1.2 cipher suites the 1.3 cipher suites do not constrain the signature algorithm and the signature_algs setting is not changed from its default.

So I was wrong when saying "the new strong configuration only supports ECDSA certificates", I should have said: the new strong configuration is only really compliant with Mozilla's specifications when used with an ECDSA certificate. I suppose we can point that out in the documentation.

Sorry for the false alarm!