Hello All, We are running BIG-IP 14.0.0.1 Build 0.0.2 Point Release 1 and attempting to configure an SSL client profile to only negotiate TLS 1.3, https://support.f5.com/csp/article/K10251520 We've configured a Cipher group to only allow TLS13-AES128-GCM-SHA256 and TLS13-AES256-GCM-SHA384. However, this breaks things. Packet captures reveal when our client hits the VIP (Chrome v70), it tries to negotiate TLSv1.2. How do we get the browser to send the initial SSL "Client Hello" request using the TLSv1.3 protocol? Right now its sending TLSv1.2 Client Hello's and VIP just responds with handshake failure. Is this a browser version setting thing or an SSL Client profile issue? Thanks All!
19-Oct-201813:47 - last edited on 02-Jun-202308:11 by JimmyPackets
Did you go to chrome://flags in the Chrome browser and enable TLS 1.3? In any case, Chrome only ever supported drafts 23 and 28 (and now the final), while BIG-IP 14.0 supports draft 26.
RFC 8446 TLS 1.3 support comes in the 14.1.
But you're on the right configuration path:
• Create a cipher rule (Local Traffic - Ciphers - Rules)
○ Cipher Suites: 'TLSv1_3'
○ Note that the above (on 14.0) only supports TLS13-AES128-GCM-SHA256 and TLS13-AES256-GCM-SHA384
○ Note that the 14.0 'DEFAULT' stack also includes the two TLS 1.3 ciphers
• Create a cipher group (Local Traffic - Ciphers - Groups)
○ Select TLS 1.3 cipher rule
• Create a client SSL profile
○ Ciphers: cipher group
○ Options List: disable 'No TLSv1.3' option
I asked several F5 employees about TLS 1.3 support during this year's Agility conference in August.
They all gave me the same answer.
The final RFC standard for TLS 1.3 would be included for client facing connections in version 14.1 expected to be released late 1st quarter/early 2nd quarter.
I asked several F5 employees about TLS 1.3 support during this year's Agility conference in August.
They all gave me the same answer.
The final RFC standard for TLS 1.3 would be included for client facing connections in version 14.1 expected to be released late 1st quarter/early 2nd quarter.
"Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade as soon as possible. For most applications this should be straight forward if they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is not an LTS release it will start receiving security fixes only with immediate affect as per our previous announcement and as published in our release strategy. It will cease receiving all support in one years time.
Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support until the end of this year. After that it will receive security fixes only. It will stop receiving all support at the end of 2019. Users of that release are strongly advised to upgrade to OpenSSL 1.1.1.
The OpenSSL team will now be moving our focus to the next release which will see us developing a new FIPS module."
"Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade as soon as possible. For most applications this should be straight forward if they are written to work with OpenSSL 1.1.0. Since OpenSSL 1.1.0 is not an LTS release it will start receiving security fixes only with immediate affect as per our previous announcement and as published in our release strategy. It will cease receiving all support in one years time.
Our previous LTS release (OpenSSL 1.0.2) will continue to receive full support until the end of this year. After that it will receive security fixes only. It will stop receiving all support at the end of 2019. Users of that release are strongly advised to upgrade to OpenSSL 1.1.1.
The OpenSSL team will now be moving our focus to the next release which will see us developing a new FIPS module."
Keep in mind that the "OpenSSL" options are relevant only to the BIG-IP's control plane. The payload traffic passing through the data plane encounters the TLS (and other protocols) as implemented in the Traffic Management Microkernel (TMM), which in general consists of proprietary code written by F5.
