Open moogle19 opened 1 year ago
@moogle19 can you please bump CI? We can also upgrade 1.13.3 to 1.14.4.
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?
@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.
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.
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).
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.
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?
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).
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!
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).