Forum Discussion
An Irule for Client Ssl Profile that Allows Unassigned TLS Extension Values (17516)
Hello Community,
I have a requirement to allow enriched https header enrichment. The SSL negotiation (I'm doing ssl termination on F5) fails because the enriched header from client contains reserved tls extension values. (https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtmltls-extensiontype-values-1).
The Client Hello request in the SSL Handshake was captured and contained an Extensions list, which included a reserved TLS Extension value (17156), which the F5 isn't presenting in Server Hello.
I need an irule that can allow that Extension to be added on the client ssl profile so the ssl handshake doesn't fail.
28 Replies
- kazeem_yusuf1
Nimbostratus
- kazeem_yusuf1
Nimbostratus
I added this irule, it created an extension actually, but there was no data under it.
when CLIENTSSL_CLIENTHELLO { set my_ext "Hello world!" set my_ext_type 17516 SSL::extensions insert [binary format S1S1a* $my_ext_type [string length $my_ext] $my_ext] }
- stan_piron
Cumulonimbus
Is this extension inserted by a public tool or are you writing your SSL client?
your code try to insert the extension in CLIENTHELLO packet
Do you want to insert it in SERVERHELLO packet?
- Kevin_Stewart
Employee
If you're trying to reflect the client's MSISDN extension to the server, you definitely want to use the SERVERSSL_CLIENTHELLO_SEND event. It does not require forward proxy to use this event.
when SERVERSSL_CLIENTHELLO_SEND { set msisdn "foobar" set bin [binary format S1S1S1S1ca* 17516 [expr [string length ${msisdn}] + 5] [expr [string length ${msisdn}] + 3] 0 [string length ${msisdn}] ${msisdn}] SSL::extensions insert $bin } - Baba_TABOURE
Nimbostratus
Hi Kazeemyu1.5586213523653357E12,
Did you have a solution on this request, Im confronted to same issue.
Exactly the same issue while im trying to perform https Client Hello Enrichment.
Regards,
Baba TABOURE
- Stan_PIRON_F5
Employee
when CLIENTSSL_HANDSHAKE { if { [SSL::extensions exists -type 17516] } then { set tls_extension [SSL::extensions -type 17516] } else { set tls_extension "" } } when SERVERSSL_CLIENTHELLO_SEND { if { $tls_sni_extension ne "" } then { SSL::extensions insert $tls_extension } }this code is a copy of this code with your extension type
https://devcentral.f5.com/s/articles/client-side-to-server-side-sni-relay-irule-967
- Baba_TABOURE
Nimbostratus
Thanks Stanislas, is this the reason why we have that kind of error sent during TLS Handshake?:
Alert (Level: Fatal, Description: Bad Record Mac).
Our F5 is the first network element we have before getting to the server.
- Baba_TABOURE
Nimbostratus
Hum ok....DO you have a summary of what you have propose and the purpose please in order to understand
- Stan_PIRON_F5
Employee
The goal of this code is:
- disable SSL profile on client side to disable TLS inspection before the code ends
- binary search the expected extension
- save in variable tls_extension_17516 the content of extension type 17516
- save in variable ext_start the index of beginning of extension 17516
- save in variable ext_len the extension 17516 length
- replace in payload the extension with no value (from ext_start with length ext_len)
missing in the code :
- change extension length to new value
- change handshake length to new value
I will update the code with missing commands later.
- Stan_PIRON_F5
Employee
I just updated the code above.
Can you try it and update this thread?
- Kazeem_Yusuf
Altostratus
As brilliant as this is.Is it possible that post-quantum cryptography may be a stumbling block to this solution, by causing tcp fragmentation. With Clienthello packets of 540bytes, this worked perfectly. An example is the "Extension Unknown Type 17516" added there.
Recent tests show the extension addition is no longer working. The only significant change is that CLIENTSSL HELLO packets are now fragmented on TLS 1.3 with the Post-Quantum Cryptography implementation on clients (browsers), with CLIENTSSL HELLO now regularly abover 1500 bytes causing fragmentation.
is it possible if F5 is Client-side server to force all clients to use X25519 ciphers instead of X25519Kyber512Draft00 and X25519Kyber768 X25519MLKEM768 to ensure that full flow is not broken. is there any changes on CLIENTSSL Profile to implement this.
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com