Add Modern cipher suites and deprecate legacy TLS.

[nortosem]

Update the :strong and :compatible cipher suite upgrades to align with modern security standards,
prioritizing TLS 1.3 and 1.2.
Remove support for the insecure TLS 1.0 and 1.1 protocols in accordance with RFC 8996.
New tests verify the correct application of these updated configurations.

[josevalim]

cc @moogle19 @voltone @realcorvus

[josevalim]

I have simplified the changes to the tests. If you are unhappy with them, please let me know. If you believe going through OpenSSL is necessary, we can do it in a single individual test and validate it rather than making most tests potentially skipped in some systems. Thank you!

[nortosem]

Looks, good! I submitted trivial changes to the test before refreshing the comments page to see [7d0c4bb], but those were mostly formatting and file name use. I'm glad we got this updated. It's been on my mind for over a year now.
The OpenSSL test is more of an integration test with plug so that could be a whole different suite of test structres.

[voltone]

Looks good to me, but it is a breaking change that could lead to issues if/when people upgrade "unexpectedly" (e.g. a weak constraint in Mix file and an enthusiastically configured Depandabot/Renovate)...

[nortosem]

@voltone Thank you for the approval and for raising this excellent point.
You're right, it is a breaking change. I intended to treat this as a security-driven feature, not a bug. Given that TLS 1.0/1.1 is formally deprecated by RFC 8996, the idea was that a failing build after an upgrade would serve as a clear, immediate signal to developers that their environment is out of compliance with current security standards.

[voltone]

Sure, and I agree it needs to be done. And I realise that an important part of any update to this particular part of Plug is going to be removing unsafe things rather than adding new things. Which necessarily means breaking changes.

My comment was not meant to express reservations about adopting the change, but more of a practical question about what it means for versioning: is this going to become Plug v2.0, or is it ok to do this in v1.19?

[nortosem]

@ voltone Of course, I see your point.
The pull request is a breaking change at the environmental level for users of older versions of Erlang/OTP. However, the cipher update preserves the plug's public API. Thus, I favor a minor version bump, since security hardening feels more like a feature of a minor release. I have also considered conducting an audit of the entire project to update any outdated SSL/TLS documentation and references, ensuring the changelog and release notes remain comprehensive.

[nortosem]

A scan of all artifacts reveals that the only documentation that needs an update to match the update to 'ssl.ex' is "guides/https.md". All other references are linked directly or indirectly to the Erlang ':ssl' application.

Now, a massive version update would be a breaking change, such as renaming 'ssl.ex' to 'tls.ex'. Renaming to 'tls.ex' is a signal of future-proofing and modernizing, and it is technically accurate. However, such a rename would be in conflict with Erlang/OTP and a massive breaking change. Therefore, in this case, it is best to document the historical inertia of this naming convention as a known quirk.

[josevalim]

💚 💙 💜 💛 ❤️

Plug v1.19-dev already bumps the minimum Elixir version from v1.10 to v1.14 and the older OTP versions are no longer maintained, so we will give a shot at doing it as a minor release. Doing a major means people can't upgrade because of ~> 1.3 checks which would then come with other issues.

Another option is to extract this into plug_crypto or plug_cyphers package which we can bump more freely.