Cirrostratus
CirrostratusHi 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 :
https://tls12.xargs.org/
it's a great Article for SSL negotiations
