it is not advisable to modify the default ssl profile, however if we would really need to disable all weak ciphers and tlsv1 protocol globally for all virtual servers, please advise beside creating a custom profile, any other solutions which we can consider, beside manually updating all virtual servers one by one. Am I right to say that all weak ciphers are disabled by default for version 11.5.3? Also please advise which firmware version by default tlsv1 is already disabled?
The default cipher suite in 11.5.3 is already sufficient to comply with current PCI DSS 3.0 requirements. Leaving the paranoid security-guru suggestions aside, there’s nothing wrong with using the DEFAULT of 11.5.3 today.
Config related:
Your only sensible option for applying a new global configuration is to create a new clientside SSL profile (i.e. clientssl_custom) which you will then re-use as the
Parent Profile
when creating you custom clientssl profiles.
The default cipher suite in 11.5.3 is already sufficient to comply with current PCI DSS 3.0 requirements. Leaving the paranoid security-guru suggestions aside, there’s nothing wrong with using the DEFAULT of 11.5.3 today.
Config related:
Your only sensible option for applying a new global configuration is to create a new clientside SSL profile (i.e. clientssl_custom) which you will then re-use as the
Parent Profile
when creating you custom clientssl profiles.
None of the firmware versions specifically disable TLSv1.0 by default. As for modifying the default SSL profile, you’re definitely correct that it isn’t advisable, but certainly doable. An alternative would be to create a new client SSL profile and assign that as the parent (or explicit) SSL profile of each VIP. If that’s untenable, and you’re also not inclined to scripting, then modifying the default cipher string in the default SSL profile might not be a bad option after all.
Take a look at the following for guidance on what’s provided, by default, in client SSL profile ciphers per version:
EAV
EAV
And: DevCentral - An F5 Technical Community
But related for newer versions.
 
But related for newer versions.
 
Updated answer. Enforcement date for 3.1 was postponed (now June 2018)
Updated answer. Enforcement date for 3.1 was postponed (now June 2018)
From Payment Card Industry Data Security Standard - Wikipedia :
3.1 was released in April 2015, and has been retired since October 31 2016.
From What’s New in PCI DSS 3.2? :
February 2018: All new requirements within PCI DSS 3.2 will become effective. (Prior to that they will be considered “best practices.”)
.
From Payment Card Industry Data Security Standard - Wikipedia :
3.1 was released in April 2015, and has been retired since October 31 2016.
From What’s New in PCI DSS 3.2? :
February 2018: All new requirements within PCI DSS 3.2 will become effective. (Prior to that they will be considered “best practices.”)
.