Forum Discussion

MaxMedov's avatar
Icon for Cirrostratus rankCirrostratus
Jun 05, 2023

Support TLS1.3 and TLS1.2 protocols

Today we are working only with TLS1.2 on SSL Clients profiles.
We are about to enable TLS1.3, and I have a few questions before a behavior about the SSL handshake process:
Case -
We are working with 3 strong ciphers supporting only 1.2 and configured as Rule in Ciphers Group.
I add another 3 strong ciphers supporting 1.3
In total = 6.
For example:

When a client who was supporting 1.2 + 1.3 negotiate a connection:
1. What protocol is he will take by default? - I guess 1.3
2. If the client who chose 1.3 didn't find the supported cipher by him from the 3 ciphers list, is he will get reset ?
Will the ry the negotiation with the ciphers from TLS1.2 ?

The goal is to continue to support all of our clients (not lose them) and support TLS1.3


9 Replies

  • MaxMedov in addition to what Mohamed_Ahmed_Kansoh has stated. Typically you have an "order" setting on the F5 when defining which SSL ciphers you will use but I do not remember the default setting for this. The following might assist you in verifying what the configuration is through the CLI and how it will appear to the client when it is used.

    The two sections are named "Configuring the SSL profile to order SSL ciphers by strength" and "View the SSL cipher order" through the GUI for configuration and CLI for verification of the cipher output. I believe the options for order are the following but I could be wrong on this.


  • Thank you both!
    So at the summary for my case
    The negotiation happened with client ciphers > and server ciphers
    If I enable 1.3 and 1.2 TLS, the negotiations will happen depending on the strongest cipher chosen it could be 1.2 or 1.3 from the group ciphers of my profile.

    • MaxMedov 
      Yes from my perspective. 

      If you encountered any issues in ssl take a packet capture for the impacted client and analysis it. 
      Have a look in the Troublshooting Article From F5 and the other one that explains the negotiations. 
      I have sent both. 
      Thanks for you and Paulius 🙂 

  • Hi MaxMedov , 

    In the Client side ssl >>> Bigip will select the best cipher that presented in the client hello which contains all supported ciphers. 
    Let say the Client send TLS1.2 ciphers , if the Bigip ip client ssl profile supports TLS1.2 as well TLS1.3 , it will work and the handshake will complete. 
    it looks like that bigip picks the one cipher from a pool of supported cipher presented by client hello message. 

    But if Big ip doesn't find a supported cipher accorfing to client ssl profile , it will give handshake_failure alert and the ssl connection will not complete. 

    Test that in a test virtual server and take a packet captures and look at { Client Hello } samples you will see a list of supported chipher suites and look at the { Server Hello } samples you will see the pivot one or the selected cipher according to your client ssl configurations. 
    if a client came with TLS1.2 and your are allowing on bigip ( TLS1.2 or TLS1.3 ) it should accept it but you must allow TLSV1.2 Ciphers in Client ssl profile which attached to your targeted virtual server. 

    Also I recommened to take a packet captures first and see which ciphers your clients send in their client hello messages , to make sure you are supporting them.

    I will attach a useful Article to troubleshoot in ssl handshakes failure and negotiations :


  • Hi Mohamed_Ahmed_Kansoh ,
    So basically, what you say is that the negotiation process is going only on the ciphers' level, and TLS option of 1.2/1.3 is only to support those ciphers or not.
    The clients only see the ciphers that the server offers them and choose from them the strongest one, it could be 1.2 or 1.3

    For example:
    If I support 6 ciphers (3 of them 1.2 and 3 1.3) and enable TLS1.2 and TLS 1.3 in profile options -
    When the client negotiates a connection, if he does have at least 1 cipher version 1.3, the process will proceed with cipher and protocol 1.3
    If the client does not have cipher 1.3 from the 3 ciphers 1.3 , but has cipher 1.2 from the list of 3 1.2 ciphers, the negotiations will proceed with this cipher.

    In any case, I don't take the ability from the existing client to connect, I just give them another option to use another 3 ciphers with TLS1.3, am I right? 

    • Hi MaxMedov , 
      This is from your last reply ( The clients only see the ciphers that the server offers them and choose from them the strongest one, it could be 1.2 or 1.3) >>>> it's the oppisit the client offers a list of cipher suites and the bigip selects the best of them , if the client sent only 3 TLS1.3 ciphers bigip will proceed in TLSv1.3 negotiations , and if the client sent TLSV1.2 list of cipher suites bigip will select the best one from the TLSv1.2 ciphers that client offered , Bigip will do that because you defined 6 Ciphers ( TLSV1.2/1.3 ) but if the Client sent TLSv1.1 it will be rejected and Handshake will fail. 

      so as you said in the examples but the Client offers and Bigip/server choose the best one compatable with client ciphers list and client ssl profile Configuarations. 

      What about having a look on this url , you'll see all ssl messages and handshakes till the ssl connection established : 
      it's a great Article for SSL negotiations 

  • MaxMedov - If your post was solved it would be helpful to the community to select *Accept As Solution*. (you may select more than one)
    This helps future readers find answers more quickly and confirms the efforts of those who helped.
    Thanks for being part of our community.

  • Hi, LiefZimmerman I made tests and it seems the results were contrasted above answers.
    It seems that if the client supports TLS 1.2 and TLS 1.3
    And F5 Supports TLS1.2 and TLS 1.3, BUT does NOT SUPPORT TLS1.3 CIPHERS that the client has, the handshake will fail and the client got reset.
    As explained to me, the client should connect with TLS1.2 ciphers if he doesn't find the matched TLS1.3 ciphers. But in fact, it stopped when he didn't find TLS1.3 only.
    There is an option called ‘LS Fallback SCSV’ , but only if the client supports it (not relevant for us):