refresh Server Side TLS guidelines: proposal for v6.0 #331
Conversation
https://pkg.go.dev/crypto/tls see 'Constants' Current code https://go.googlesource.com/go/+/refs/heads/master/src/crypto/tls/cipher_suites.go#678 Since Go 1.14 (released Feb 2020), Go added to constants + // Legacy names for the corresponding cipher suites with the correct _SHA256 + // suffix, retained for backward compatibility. + TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 = TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 + TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 = TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 https://go.googlesource.com/go (mirror https://github.com/golang/go/) commit e2cac315082a9267135e96249b537d0bd0703175 crypto/tls: add correct names for CHACHA20_POLY1305 cipher suite constants The cipher suites were apparently renamed late in the standardization process, and we picked up the legacy name. We can't remove the old constants, but add correctly named ones. Older versions of Go < 1.14 (now almost 5 years old) need to use TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 instead of TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 Note also that some older ciphers are disabled by default in Go https://go.dev/doc/godebug Go 1.23 changed the default TLS cipher suites used by clients and servers when not explicitly configured, removing 3DES cipher suites. The default can be reverted using the tls3des setting. Go 1.22 changed the default TLS cipher suites used by clients and servers when not explicitly configured, removing the cipher suites which used RSA based key exchange. The default can be reverted using the tlsrsakex setting. Go crypto/tls configurable settings: https://pkg.go.dev/crypto/tls#Config This commit removes most of the special-casing done in 2020 in Use caddy ciphers from JSON file mozilla#108
previous rendering of guidelines assumed hsts and ocsp enabled and the URL logic appened value if false. This change inverts that logic and makes includes of &hsts&ocsp sufficient to indicate enabled, not requiring =true. Absence of those tags indicates disabled or false. OCSP checkbox is no longer checked by default. Let's Encrypt plans to sunset its OCSP responders this year (2025) (and has blogged about its reasoning; not repeated here)
- remove kDHE ciphers from Intermediate and Old recommended ciphers for Intermediate are now all PFS with AEAD - change Old dhParamSize from 1024 to 2048 and use ffdhe2048 instead of locally generated dhparams - remove 'go' and 'caddy' cipher list from guidelines; instead use IANA cipher names and supportedCiphers list in configs.js to filter ciphers supported by Go crypto/tls module Not part of guidelines, but part of ssl-config-generator: - For HSTS, use HTTP status code 308 Permanent Redirect for redirecting all http:// to https:// The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect) https://www.rfc-editor.org/rfc/rfc7238 (published June 2014) - invert hsts and ocsp logic; disable ocsp default Not (yet) included in this PR: - consider removing all 3DES and CBC ciphers from Old; leave only ECDHE e.g. remove all ciphers in Go InsecureCipherSuites() list // InsecureCipherSuites returns a list of cipher suites currently implemented by // this package and which have security issues. https://go.googlesource.com/go/+/refs/heads/master/src/crypto/tls/cipher_suites.go#75 - consider removing Old configuration; it should not be used If needed, consumers can refer to 'Intermediate' and 'Old' generated from older versions of ssl-config-generator application obtained from the Internet Archive (archive.org)
- remove "Old" configuration; "Old" configuration is not recommended For those who need to reference older guidance, older versions of the ssl-config-generator may be obtained from the Internet Archive (archive.org) https://web.archive.org/web/*/https://mozilla.github.io/server-side-tls/ssl-config-generator/
|
Please also take into account PQC key exchange (X25519MLKEM768) as supported by modern browsers. |
Agree. Should be considered for Modern config, when supported by TLS libraries. |
Why only Modern? All profiles have the same level of forward compatibility, only different backwards compatibility? |
|
Yes, we should definitely include PQC in the TLS groups (curves) listing. in all security levels. I would say that the X25519MLKEM768 is absolute minimum, Secp256r1MLKEM768 should be included too (will be supported, or already is supported by Firefox), I do wonder about Secp384r1MLKEM1024... that one is a bit further away with support in Firefox, otoh, we do include secp384r1 in the curves already, so including PQC hybrid variant of it in the listing would be consistent... |
|
In light of lamps-wg/draft-composite-kem#123 I wouldn't necessarily support all possible combinations. (a backup KEM can be added once standardized, eg. based on HQC, but additional ML-KEM hybrid's aren't backups) |
the others are there to meet operational requirements, not interoperability requirements, there very likely will be environments which cannot use x25519, or are required to use ML-KEM-1024 |
Sorry to be late to this thread. As @tomato42 alludes to, only ML-KEM-1024 is allowed by CNSA 2.0 and the Australian equivalent. Also, X25519 is not universally-allowed, so many applications will require a P-256 variant. I would suggest that you want two Mandatory-To-Implements:
and RECOMMENDED support for MLKEM1024+P384. |
The existing Mozilla Server Side TLS guidelines are from 2020 (with one small change since) and are long overdue for review and update.
As a member of Mozilla SSL Config Generator working group, I have compiled the following proposal for a new version of the Mozilla Server Side TLS guidelines. My intent in this PR is to update the guidelines in line with existing recommendations from CDNs and other large tech companies; I do not believe that any of the changes are ground-breaking.
This proposal is being filed as a PR to the ssl-config-generator repository in order to have the changes available as git diffs for review. Please review the commits in this PR individually and sequentially to visualize the changes.
To set some expectations: this PR is being submitted for review and comment on the proposed changes herein. If there are other items that knowledgable parties would like to suggest changing, please file them as separate issues at
https://github.com/mozilla/server-side-tls/issues and they will be considered there for this or a future update to the guidelines.
Thank you!
guideline 5.8 proposed changes
remove kDHE ciphers from Intermediate and Old
change Old dhParamSize from 1024 to 2048 and
use ffdhe2048 instead of locally generated dhparams
DHE ciphers should be disabled in Intermediate compatibility configuration server-side-tls#268
Stop recommending DHE, because of "dheater" vulnerability server-side-tls#299
meta: recommended ciphers for Intermediate are now all PFS with AEAD.
Today, in 2025, this is widely supported on the internet.
Impact: no longer support IE11 on Windows 7 in Intermediate and Modern configs.
Today, in 2025, IE11 and Windows 7 should be omitted from the the public
Mozilla Server Side TLS guidelines for Intermediate or Modern configs.
ssl-config-generator rendering/behavior changes:
https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls/
https://letsencrypt.org/2024/12/05/ending-ocsp/
Remove OCSP recommendation #323
so that HTTP methods which are not GET or HEAD are redirected without method change to GET
https://www.rfc-editor.org/rfc/rfc7238 (published June 2014)
308 Permanent Redirect #117
guideline 6.0 proposed changes
For those who need to reference older guidance, older versions of
the ssl-config-generator may be obtained from the Internet Archive
https://web.archive.org/web/*/https://mozilla.github.io/server-side-tls/ssl-config-generator/
Alternatively, the current ssl-config-generator will continue to render URLs which specify older guideline versions (e.g.
&guideline=5.7) and will contain the recommendations in the older guideline (e.g. cipher lists), but the rendering may not exactly match what was produced years ago since the ssl-config-generator presentation may have changed in the interim.