Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Updated SSL/TLS defaults #1143

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

moogle19
Copy link
Contributor

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
Copy link
Member

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

TLS1.3 doesn't support secure_renegotitate or reuse_sessions
which is set to true by default.
By moving the set_secure_defaults after the configuration,
the correct options are set
@moogle19
Copy link
Contributor Author

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
Copy link
Member

@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
Copy link
Contributor

voltone commented Apr 11, 2023

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
Copy link
Member

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).

lib/plug/ssl.ex Outdated Show resolved Hide resolved
@voltone
Copy link
Contributor

voltone commented Apr 11, 2023

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
Copy link
Member

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
Copy link
Contributor Author

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
Copy link
Contributor

voltone commented Apr 11, 2023

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!

Co-authored-by: Bram Verburg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants