Cipher Rules And Groups in BIG-IP v13

Hi  ;

Popular browsers are commonly ahead of enterprise application development. Those updates can cause as many disruptions to internal infrastructure as well as larger SaaS solutions that still rely on existing and established security standards & practices. This article was written for v13 which predated a lot of recent public and private browser behavior changes and security recommendations. I'll check out updating it for v15 if there are discrepancies.

In another article series I brought up a case where Google Chrome devs made an arbitrary and not-widely communicated decision to drop secp521r1 simply because they didn't see many people using it. But given it was ECC and performance was not a hindering factor, a lot of high security departments implemented internally (and because it was in the approved lists at the time). Google's decision broke entire internal CA infrastructure. Those companies rely on best practices and not what Google or Mozilla decide for us.

Mozilla's recommendations are geared towards trending-edge security which is great from forward thinking perspective or smaller lightweight apps that can update quickly but we've also seen those recommendations break as many applications and possibly cause performance issues when people didn't understand the ramifications of new settings on existing systems during high volume traffic. If you note the modern config on Mozilla's config generator states "Services with clients that support TLS 1.3 and don't need backward compatibility". That backward compatibility is often required by industries and Fed sectors that hard lock a specific vendor configuration.

Regarding v14's support of TLS 1.3. Megazone's comment in this article from last year correctly stated that we released v14 prior to TLS 1.3 moving out of draft 26.

"Those new fields are for TLSv1.3, which is only Draft 26 support in 14.0.x, so not that useful yet. (14.1.0 should have RFC TLSv1.3 support.) They're part of the changes in TLSv1.3 - the signature algorithm is no longer specified as part of the cipher suite, and you can now specify the parameters for (EC)DH(E)." - Megazone

14.1.0.1+ supports the the RFC 8446 for TLS 1.3. More here: K10251520

In v14.1.0.1+ if you run tmm --clientciphers tlsv1_3 you get:

ID  SUITE                            BITS PROT    CIPHER              MAC     KEYX
 0:  4865  TLS13-AES128-GCM-SHA256          128  TLS1.3  AES-GCM             NULL    *         
 1:  4866  TLS13-AES256-GCM-SHA384          256  TLS1.3  AES-GCM             NULL    *         
 2:  4867  TLS13-CHACHA20-POLY1305-SHA256   256  TLS1.3  CHACHA20-POLY1305   NULL    *

The good question/discussion you bring up is related to f5-default and f5-secure... the rule of thumb within the DevCentral community and F5's support is to use default or whatever prebuilt cipher list as a starting point and not rely on them as your configuration source of truth. The cipher suites can and usually change with each version and sometimes hotfix and you don't want dynamically updating cipher suites for your applications: start with default or secure and work from there. You definitely don't want to be using default and have it change and your application break because of a hot fix upgrade. That's why this article was written, to make managing cipher suites easier for the non-security professional.

Your discussion that you want a think a more intuitive approach for those who don't want to spend too much time in deciding what is good or wrong is very valid and makes a lot of sense for current application developers. That's something we can bring back to dev groups and discuss and a lot of this functionality grew out of the many industries we have to support, not just software applications. It could be time to review or name things a bit nicer OR even include a few new cipher lists that have app dev in mind.

Thanks for commenting, it was a good discussion point to an article written a while ago and probably needs some dusting off.