I agree with your statement on having opinionated, secure defaults.
In this case however I do believe that having a config override is a good idea.
Two examples come to mind (both based past experience):
1. A client may have a standard operating environment that mandates an
older version of a browser (scary!) or Java version (e.g. JVM running an application that interacts with the OpenStack API). The client may wish to use old/insecure protocols/ciphers for compatibility reasons.
2. A client's independent pentester may recommend (e.g. flag as
"MEDIUM" severity) that certain protocols/ciphers be disabled. The client may wish to disable protocols/ciphers that are still used "in the wild" (but not internally).
Mozilla provides a good SSL config generator that can be tweaked to give you some idea of how clients will be effected: https://ssl-config.mozilla.org/
I agree with your statement on having opinionated, secure defaults.
In this case however I do believe that having a config override is a good idea.
Two examples come to mind (both based past experience):
1. A client may have a standard operating environment that mandates an
older version of a browser (scary!) or Java version (e.g. JVM running an application that interacts with the OpenStack API). The client may wish to use old/insecure protocols/ciphers for compatibility reasons.
2. A client's independent pentester may recommend (e.g. flag as
"MEDIUM" severity) that certain protocols/ciphers be disabled. The client may wish to disable protocols/ciphers that are still used "in the wild" (but not internally).
Mozilla provides a good SSL config generator that can be tweaked to give you some idea of how clients will be effected: https:/ /ssl-config. mozilla. org/