on
28-Feb-2017
03:00
- edited on
05-Jun-2023
22:42
by
JimmyPackets
My mother used to always tell me two things before I left for school in the morning.
You may have had a different upbringing from me but my mom's lessons still apply to anyone using SSL/TLS enabled systems. We know from Señor Wagnon's Security Sidebar: Improving Your SSL Labs Test Grade how cumbersome modifying lengthy cipher strings can be to keep your SSL Labs A grade. We know as BIG-IP matures we update the DEFAULT cipher list to remove deprecated entries and introduce fancy new ones. This causes negative affects on those legacy applications we like to keep lying around. Lastly, we know that not everyone appreciates meditating in SSH sessions; pondering countless tmm --clientciphers commands to figure out what cipher string they'll need in order to get achieve an SSL Labs A+ grade. We have a solution for you.
BIG-IP version 13 introduces Cipher Rules & Groups; an alternate way to visualize, organize, and apply cipher suites to your client and ssl profiles. You still need a basic understanding of cipher strings and I recommend you review Megazone's article: Cipher Suite Practices and Pitfalls article before gallivanting through Cipher Rules & Groups; you'll stub a toe. Cipher rules and the subsequent groups that contain them allow the same boolean operators used in tmm cipher strings.
F5 includes 5 default cipher rules and applies them via 5 default cipher groups of the same name (included is the tmm command to view each cipher list used):
tmm --clientciphers AES
tmm --clientciphers DEFAULT
tmm --clientciphers ECDHE:ECDHE_ECDSA
tmm --clientciphers ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES
tmm --clientciphers 'ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-CBC-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-CBC-SHA:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:RC4-SHA:RC4-MD5:DHE-RSA-DES-CBC-SHA:DHE-RSA-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:!TLSv1:!TLSv1_1:!SSLv3:!DTLSv1
The last one related to HSM ciphers was crazy long wasn't it. This is why we built cipher rules and groups; to prevent you from banging your head on the table because you got the operand wrong somewhere after ECDHE-RSA-AES128-GCM-SHA256. The F5 provided rules and groups are read-only and should used as a reference or starting template. If you rely only on the default F5 cipher rules/groups they will change as our cryptographic requirements change and you could end up with a bunch of incompatible legacy clients.
Because Cipher Rules and Groups are applied to SSL Profiles, you can find them under Local Traffic in the web GUI. Clicking into Local Traffic => Ciphers gives you two options: Cipher Rules and Cipher Groups. I'll create one Cipher Rule based on tmm cipher string ALL:SSLv3:EXPORT. This is only for display purposes to better illustrate the boolean operations when we build the Cipher Group. Current ciphers based on BIG-IP version and Hotfix are listed in the NATIVE cipher list. Remember, we have to support a lot of ciphers that may not be appropriate for public consumption.
Now we'll build a Cipher Group starting with the chase_all Cipher Rule, because we're gluttons for punishment. Clicking the + expands the ciphers allowed under each Cipher Rule. Adding it to the "Allow the following" element, the Cipher Audit element below will automatically update to reflect the ciphers this group will provide the Client or Server Profile. Remember, anything added in that window is performing a Boolean Union operation.
Adding the f5-aes Cipher Rule to the "Restrict the Allowed List to the following:" element which will reduce the chase_all cipher list to only ciphers common to both ALL:SSLv3:EXPORT and AES lists; performing a Boolean Intersection operation. The Cipher Audit element shows the results and we can see those pesky RC4-MD5 suites from EXPORT are gone, but ew... we have some SSLv3-enabled ciphers and we want those out. I'll create a new Cipher Rule called chase_sslv3 with the cipher string only being SSlv3. I'll add this new Cipher Rule to the "Exclude the following from the Allowed List:"; performing a Boolean Difference operation. We can also change the cipher sorting based on speed, strength, FIPS, or hardware accelerated via the Order dropdown.
Ahh.... better, now we've paired down a horribly insecure cipher list with the intersection of the AES ciphers and exclusion of the SSlv3s. Yea, we could have started with the AES Cipher Rule as the base list but that's not as fun for this demonstration. The lifecycle of a BIG-IP SSL profile requires active management of cipher suites. This demo illustrates the flexability of additive/subtractive cipher management which reduces the complexity of recreating the wheel every time someone nullifies the security of existing algorithms or hash functions.
Open an SSL Client or Server Profile and change the configuration to advanced. The cipher list becomes available and is defaulted to a Cipher String. Now you have a radio button for Cipher Group, selecting the newly created object or click the + button to create one from scratch.
We have support for tmsh commands so you can take advantage of adding cipher groups to existing profiles.
# tmsh list ltm cipher rule f5-secure all-properties ltm cipher rule f5-secure { app-service none cipher ECDHE:RSA:!SSLV3:!RC4:!EXP:!DES description "Cipher suites that maximize regulatory compliance." partition Common }
# tmsh show ltm cipher rule f5-secure ----------------- Ltm::Cipher::Rule ----------------- Name Result ----------------- f5-secure ECDHE-RSA-AES128-GCM-SHA256/TLS1.2:ECDHE-RSA-AES128-CBC-SHA/TLS1.0:ECDHE-RSA-AES128-CBC-SHA/TLS1.1:ECDHE-RSA-AES128-CBC-SHA/TLS1.2:ECDHE-RSA-AES128-SHA256/TLS1.2:ECDHE-RSA-AES256-GCM-SHA384/TLS1.2:ECDHE-RSA-AES256-CBC-SHA/TLS1.0:ECDHE-RSA-AES256-CBC-SHA/TLS1.1:ECDHE-RSA-AES256-CBC-SHA/TLS1.2:ECDHE-RSA-AES256-SHA384/TLS1.2:ECDHE-RSA-DES-CBC3-SHA/TLS1.0:ECDHE-RSA-DES-CBC3-SHA/TLS1.1:ECDHE-RSA-DES-CBC3-SHA/TLS1.2:AES128-GCM-SHA256/TLS1.2:AES128-SHA/TLS1.0:AES128-SHA/TLS1.1:AES128-SHA/TLS1.2:AES128-SHA/DTLS1.0:AES128-SHA256/TLS1.2:AES256-GCM-SHA384/TLS1.2:AES256-SHA/TLS1.0:AES256-SHA/TLS1.1:AES256-SHA/TLS1.2:AES256-SHA/DTLS1.0:AES256-SHA256/TLS1.2:CAMELLIA128-SHA/TLS1.0:CAMELLIA128-SHA/TLS1.1:CAMELLIA128-SHA/TLS1.2:CAMELLIA256-SHA/TLS1.0:CAMELLIA256-SHA/TLS1.1:CAMELLIA256-SHA/TLS1.2:DES-CBC3-SHA/TLS1.0:DES-CBC3-SHA/TLS1.1:DES-CBC3-SHA/TLS1.2:DES-CBC3-SHA/DTLS1.0
# tmsh list ltm cipher group chases_cipher_group all-properties ltm cipher group chases_cipher_group { allow { chase_all { } } app-service none description "MY CIPHERS ARE THE BEST CIPHERS" exclude { chase_sslv3 { } } ordering default partition Common require { f5-aes { } } }
# tmsh show ltm cipher group chases_cipher_group --------------------------- Ltm::Cipher::Group --------------------------- Name Result --------------------------- chases_cipher_group ECDHE-RSA-AES128-CBC-SHA/TLS1.0:ECDHE-RSA-AES128-CBC-SHA/TLS1.1:ECDHE-RSA-AES128-CBC-SHA/TLS1.2:ECDHE-RSA-AES128-SHA256/TLS1.2:ECDHE-RSA-AES256-CBC-SHA/TLS1.0:ECDHE-RSA-AES256-CBC-SHA/TLS1.1:ECDHE-RSA-AES256-CBC-SHA/TLS1.2:ECDHE-RSA-AES256-SHA384/TLS1.2:ECDH-RSA-AES128-SHA256/TLS1.2:ECDH-RSA-AES128-SHA/TLS1.0:ECDH-RSA-AES128-SHA/TLS1.1:ECDH-RSA-AES128-SHA/TLS1.2:ECDH-RSA-AES256-SHA384/TLS1.2:ECDH-RSA-AES256-SHA/TLS1.0:ECDH-RSA-AES256-SHA/TLS1.1:ECDH-RSA-AES256-SHA/TLS1.2:AES128-SHA/TLS1.0:AES128-SHA/TLS1.1:AES128-SHA/TLS1.2:AES128-SHA/DTLS1.0:AES128-SHA256/TLS1.2:AES256-SHA/TLS1.0:AES256-SHA/TLS1.1:AES256-SHA/TLS1.2:AES256-SHA/DTLS1.0:AES256-SHA256/TLS1.2:ECDHE-ECDSA-AES128-SHA/TLS1.0:ECDHE-ECDSA-AES128-SHA/TLS1.1:ECDHE-ECDSA-AES128-SHA/TLS1.2:ECDHE-ECDSA-AES128-SHA256/TLS1.2:ECDHE-ECDSA-AES256-SHA/TLS1.0:ECDHE-ECDSA-AES256-SHA/TLS1.1:ECDHE-ECDSA-AES256-SHA/TLS1.2:ECDHE-ECDSA-AES256-SHA384/TLS1.2:ECDH-ECDSA-AES128-SHA/TLS1.0:ECDH-ECDSA-AES128-SHA/TLS1.1:ECDH-ECDSA-AES128-SHA/TLS1.2:ECDH-ECDSA-AES128-SHA256/TLS1.2:ECDH-ECDSA-AES256-SHA/TLS1.0:ECDH-ECDSA-AES256-SHA/TLS1.1:ECDH-ECDSA-AES256-SHA/TLS1.2:ECDH-ECDSA-AES256-SHA384/TLS1.2:DHE-RSA-AES128-SHA/TLS1.0:DHE-RSA-AES128-SHA/TLS1.1:DHE-RSA-AES128-SHA/TLS1.2:DHE-RSA-AES128-SHA/DTLS1.0:DHE-RSA-AES128-SHA256/TLS1.2:DHE-RSA-AES256-SHA/TLS1.0:DHE-RSA-AES256-SHA/TLS1.1:DHE-RSA-AES256-SHA/TLS1.2:DHE-RSA-AES256-SHA/DTLS1.0:DHE-RSA-AES256-SHA256/TLS1.2:DHE-DSS-AES128-SHA/TLS1.0:DHE-DSS-AES128-SHA/TLS1.1:DHE-DSS-AES128-SHA/TLS1.2:DHE-DSS-AES128-SHA/DTLS1.0:DHE-DSS-AES128-SHA256/TLS1.2:DHE-DSS-AES256-SHA/TLS1.0:DHE-DSS-AES256-SHA/TLS1.1:DHE-DSS-AES256-SHA/TLS1.2:DHE-DSS-AES256-SHA/DTLS1.0:DHE-DSS-AES256-SHA256/TLS1.2:ADH-AES128-SHA/TLS1.0:ADH-AES256-SHA/TLS1.0
# tmsh list ltm profile client-ssl chases_ssl_client_profile ltm profile client-ssl chases_ssl_client_profile { app-service none cert default.crt cert-key-chain { default { cert default.crt key default.key } } chain none cipher-group chases_cipher_group ciphers none defaults-from clientssl inherit-certkeychain true key default.key passphrase none }
# tmsh list ltm profile server-ssl chases_ssl_server_profile ltm profile server-ssl chases_ssl_server_profile { app-service none cipher-group chases_cipher_group ciphers none defaults-from serverssl }
A lot of users are not always comfortable with how we output our cipher lists. NMAP provides a user-preferred display using the ssl-enum-ciphers script. In this case, we'll check out SSL Labs web server's ciphers. Run the following:
$ nmap -Pn -sT www.ssllabs.com -p 443 --script ssl-enum-ciphers Starting Nmap 6.40 at 2017-02-24 11:22 PST Nmap scan report for www.ssllabs.com (64.41.200.100) Host is up (0.035s latency). PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | SSLv3: No supported ciphers found | TLSv1.0: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL | TLSv1.1: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL | TLSv1.2: | ciphers: | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 - strong | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - strong | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 - strong | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - strong | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | compressors: | NULL |_ least strength: strong Nmap done: 1 IP address (1 host up) scanned in 2.73 seconds
Hopefully this overview and mini-demo got you pondering how you can improve cipher management in your infrastructure. As the crypto world discovers new ways to compromise math, we have to keep on our toes more than ever. Google Research and CWI Amsterdam just published the first real world hash collision for SHA-1 proving we need to stay informed. The idea is simple, create Cipher Rules based on your needs and reuse them against application or security policy-centric Cipher Groups. Segregating Cipher management from Client and Server SSL Profiles creates a more flexibility for application owners and should reduce the cipher string headache every time there's a new vulnerability. Drop us a line on your thoughts and let us know if we're going down the right path or if ther are other things you wish to see related to cipher management.
Keep it real.
Very useful article! Many thanks for your explanation.
Best Regards
Antonio
Be careful.
We started using Cipher Rules/Groups in an effort to standardize the management of ciphers in all the VS we manage. What we found was that if you make a change to an existing Cipher Rules (add or restrict ciphers), those modifications are NOT applied to the SSL Profiles where that Cipher Group was previously applied. Instead, we had to de-apply and re-apply the cipher group to each and every SSL profile in order for them to pick up the changes. Since the Cipher Rule / Group is a more centralized approach to managing cipher strings, I would have expected that changes made to those Rules/Groups would have permeated to the SSL profiles in which they were applied. Keep in mind that your SSL Profile will still show the name of the Cipher Group you just modified, but the changes you made to that Cipher Group will not be reflected in the ciphers offered by your VS. F5 suggested we reload the config through CLI for those changes to be picked up, but we did not want to possibly impact the production environment so I cannot report whether that would have resolved our situation.
@Benoit;
That's a great point to illustrate! The profile server has to be "recompiled" in tmm micro kernel to update configuration changes. It lives in a static state when a save is made so de-applying/re-applying updates the virtual and forces the new config save with updated data. I will add this that requirement to the article.
There are several places where a profile or virtual server will not see changes until it's "saved" again to recompile in tmm.
@Chase,
Thanks for your time. Is there a simpler way than de-applying / re-applying individually to each SSL Profiles? Is there (I wish! I wish!) a tmm command to force the recompilation for all profiles having a Cipher Group applied? Having to do this manually for close to a hundred profiles is tedious and I otherwise don't see much benefit to the new command compared to individually pasting the cipher string to the SSL profile. Would a "load /sys config partitions all" also do the trick? (albeit a bit more drastic).
Thank you.
Running v13.1.0.3.0.0.5 I created a benoit-test cipher group, benoit-test ssl profile, for my benoit-virtual. Changing cipher rules in the group did apply the update directly. I started with the default string and then restricted the group to ECC only. The change did update without having to mess with the SSL profile.
Second test was only updating the rule string. I created a benoit-test for a rule and used the
ECDHE:ECDHE_ECDSA
string. I got back 13 ciphers. I then added !TLSv1 and !TLSv1_1 to the rule list ONLY, no update to the cipher group. The updated rule list DID change the returned cipher list, narrowed down to 6 cipher.
I am using the article's nmap ssl-enum-cipher script to verify change.
What version are you on?
Hi @Chase,
Running 13.1.0.2 at the moment. Had opened case number C2659062 at the time and the engineer informed me that he had reproduced my situation but that this was not on the road map to fix.
Question: When you say "The updated rule list DID change the returned cipher list, narrowed down to 6 cipher" do you mean in the Audit portion of F5 or what is actually being offered by the VS to a connecting client? When testing, all indications on F5 were that the list was updated, but the ciphers being offered on the wire remained unchanged.
Thank you immensely for your time.
Hi,
I did the same test (13.1.0.6 on VE) as Chase and no live update 😞
Steps:
Piotr
@Piotr,
That's exactly my point. After you've changed your cipher group configurations, you have to go to each client profile, select another cipher group, save, re-select your original one, save, in order for your cipher group changes to be applied. This is counter-intuitive, time consuming and prone to omissions if you have a large number of client profiles using that cipher group.
It can also be misleading since Big-IP's cipher audit lists what should be expected, not what the VS actually supports after the change. Could also be a security concern where administrators may think they patched a security issue with weak protocols / ciphers when in fact they will not have.
I'm a bit disappointed. Unless it is fixed, I now feel that it's better to have the cipher string directly in the client profile instead of a Cipher Group. With a Cipher Group, if you made changes to the group you don't know if your profile needs "updating" or no. With a cipher string, what you have there is what you get, so there is no misunderstanding. Cipher Groups would be a great way to standardize and simplify cipher string configurations if changes could automatically permeate to all the Client SSL profiles on which they are applied.
Hi Ben,
I have to agree - quite a disappointment. I never expect that it is rather static config and do creates such unpredictable situations. I only hope it will be fixed in the future.
Piotr
@Ben;
I ran nmap cipher script to validate what the virtual sever was sending a client session. I'll follow up on that ticket and if I had an invalid test. If thats the case, I will ensure the impact of this issue. I'll revalidate the test and steps I used and report back on this.
I also agree with your assertion that this could be a security issue if a cipher list was updated but application endpoints were not tested to validate. This would be the correct argument to have this remedied in the software.
@Ben;
I reviewed the case with the engineer and the issue in the ticket isn't quite related to what we're discussing. In your case you needed a DSS cipher which required a different key exchange (DSA) from what was supplied in your SSL profile cert/key (RSA). I don't see where cipher group changes did not propagate to the profile and subsequent virtual servers. Was that specifically discussed with the engineer?
You did have a very interesting issue where the cipher suite modifications would introduce an issue by allowing an incompatible cipher to try and answer on behalf of the RSA key exchange. RSA and DSA keys are not interchangeable so while the cipher suite can be modified to allow a DSS exchange within the cipher list, it doesn't mean it's going to work. Thank goodness for iRules.
@Piotr;
I am still going to rerun my config. My test was simple in that I was only examining the NMAP output between changes in a cipher group but I don't remember the string that I modified the cipher group from/to. I'll post my updated test to a Q&A discussion so I can show the code. I am at the Global Service Tech Summit right now so I won't be able to get back to testing until next week sometime.
-Chase
@Chase,
First, my apologies for misleading you. The case in question was actually C2590010 which was later followed by C2632482, not the one about RSA vs. DSA.
Second, I think I nailed the symptoms. Running 13.1.6 in my lab, I'm using "TestSSLServer" on a client PC to test what ciphers are supported by the F5 VS. I created a node, pool, SSL Client profile, VS (20.1.1.10%8) and cipher rule/group in the Common partition. Then I also created a new partition in the same route-domain as Common (%8 in my case) so routes,self-IPs and all are shared. In that partition, I created a new pool, SSL profile, VS (20.1.1.30%8), etc. I used the same Cipher Group found in the Common partition for that profile.
With "DEFAULT" as cipher string in the cipher group, both VS presented the same ciphers through TestSSLServer. Then I changed the cipher string to "DEFAULT:!TLSv1:!TLSv1_1" in that Cipher Rule and ran the same tests using TestSSLServer. The VS at 20.1.1.10%8 in the Common partition picked up the updates and presented only TLS1.2 ciphers. The VS at 20.1.1.30%8 in the other partition did not, and still presented TLS1.0 and 1.1 ciphers. I then manually went to the SSL Client profile in the customer partition, picked one of the vanilla F5 Cipher Groups, applied, re-selected my original Cipher Group from common, applied, ran TestSSLServer once more and it then presented the correct TLS1.2 only ciphers.
So, it seems that the propagation of the Cipher Group changes in "Common" were propagated to the SSL Client profile in that same partition, but not to the one in custom partition.
Simple to recreate: build a Pool/VS/Client SSL Profile in Common and one in a separate partition, both using the same Cipher Group configured in Common, make changes to the Cipher Rule and observe the results. I'm about to test with 13.1.7.
Hope this helps.
THAT makes a lot more sense, both in support ticket data and in your testing. I didn't test separate partitions. If that's by design I'll escalate.
Meh... either way I'll escalate because as you stated before, it's a security issue if you think you're bumping up everyone to an SSL A+ and the change doesn't propagate out to tenanted customer configs.
Hi,
@Chase - Thanks a lot for all info provided.
Did you try to perform steps I described (in fact it's replication of your steps). For me change in ciphers (excluding TLSv1 and TLSv1_1) occurred only after I unsigned and then assigned again Client SSL profile. Only after this step only TLSv1_2 cipher was listed by nmap. All objects used in my test was created in Common partition.
Piotr
Found this little guy from the internal case notes: https://cdn.f5.com/product/bugtracker/ID681814.html
It did get assigned a bug ID and is slated to fix. I couldn't find any exact dates or release numbers where a code fix will roll up to. That's the ONE system I don't have eyes in. Of course. 😉
Sounds like our puppy yes 🙂
Two quick questions then:
Does the workaround refer to doing a "tmsh load /sys config partitions all" ?
With redundant appliances, this command would need to be performed on both?
Is there an order of preference? (Active first then Standby or vice versa?)
Is there an operational impact with performing this command or would feel safe doing this right smack in the middle of the work day?
Thanks again for your time on this 🙂
Hi,
Thanks for update. What puzzles me in the referenced bug description is that it seems to be related only to 13.0.x version. There is no indication it was discovered in 13.1.x version - one I used for testing.
Piotr
Hi,
I just checked Bug ID 681814: Changes to a cipher group are not propagated to SSL profiles until the configuration is reloaded mentioned by Chase.
According to Bug Tracker https://cdn.f5.com/product/bugtracker/ID681814.html issue is fixed in 14.0.0.
So Cipher Groups should be a way to go now!
Piotr
Hi Chase,
No problem 🙂
Do you know by chance how DH Groups and Signature Algorithms (new fields in v14) can be used when creating Cipher Rule?
Piotr
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).
Hi,
Thanks a lot for info. I was not able to find any info on AskF5 😞
Piotr
It's good to know that you provide fine tuning for people who want to go deep in cipher management, but I would also appreciate a more intuitive approach for those who don't want to spend too much time in deciding what is good or wrong, based on Mozilla's recommandations for instance : max compatibility (not recommended) / Intermediate / Modern (max security) / Custom...
I'm surprised to see that in v14 the default "Clientssl" profile comes with the "No TLSv1.3" option enabled, why did you chose to exclude it by default ?
Also, why does the Cipher Rule "f5-default" comes with TLS1.3 whereas "f5-secure" doesn't use it ? I would have expected the opposite
Thanks anyway for the effort
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.
Thanks a lot Chase, for both your interesting article and feedback ! I learned a lot.
The reason I'm putting this on the table is because I just upgraded from v12 to v14.1.2 and a lot of warnings were raised in the upgrade log file related to Ciphers in SSL profiles, The upgrade procedure created a new server SSL profile by the name my first https monitor in the alphabetical order, and applied it to all my https monitors ... That was kind of an unexpected behavior, so I did my researches and ended up here, wondering what was the best way to move back closer to the F5 standards 🙂
And I must confess I'm still not sure about the best config I can make, because your exemple shows what can be done with the new tool, but not what should be done to get an A at Qualys scan for instance ...
BTW, that could also be a way to make the cipher list management more user-friendly to sort them by Qualys rating "as of the day of the tmos release". Today that's how I proceed, by publishing a test website online and running the scan to see if my SSL profile is fine, but it takes time and it requires a public access to the website, not everyone have both 🙂
Hi,
@Chase - great explanation!
Just small note for people using vCMP - it was a bit surprise for me, so maybe worth sharing 🙂 According to K10251520: BIG-IP support for TLS 1.3 if you want to use TLS 1.3 on vCMP guest you need both host and guest running at least 14.1.0.1. Not obvious part is that 14.1.x.x is required as well for host.
Piotr
Good point! 14.1.0.1+ for everything to properly support it (my screen shot was of v15 but it's the same as v14 so c'est la vie).
Your upgrade from 12 to 14.1.2 had a lot of security happenings between those versions and your experience was definitely odd. Were you using the default ServerSSL profile? My rule of thumb from experience (on version 10 when we tested the first Exchange 2010 iApp) was to create all new profiles and break inheritance for any potential impacting settings. That was something learned the hard way even with the developers 100 meters away.
Regarding the SSL Labs A grade, I like this idea and will explore it further with my team and possibly support. Given current BIG-IP releases are spaced farther apart than SSL Labs updates sometimes, we can either cover it in documentation and include maybe a cipher group config output or something. I like this idea though of reexamining our cipher groups and maybe naming better aligned to the suites contained within.
Good ideas all around and it would definitly make the features easier to understand and use!
Hi
It would be great to have base profile providing A grade (at the time of version release) but for sure this is not easy. Having dedicated article (updated in pair with SSL Labs changes) seems to be easier way but for sure it will be great help for people like me not being TLS expert. Great idea, hope it will catch up.
Piotr
Great Article and huge improvement in Cipher management.
I have struggled and spent too much time managing Ciphers to keep up with Vulnerability scanners and Pen test results.
I can't wait to test it out in production and make Security team happy with a little but smart effort from my team.
😃 👊 👏