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.
27 Replies
- 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.
- Kazeem_Yusuf
Nimbostratus
Your code is great. i would like to ask though. In cases where some packet gateway equipment uses legacy systems, and has a challenge with fragmenting tls headers, such that, there is inconsistency in inserting extension header 17516. how can F5 be used to catch and stop the fragmentation. For example. An explanation for how it works goes thus. "The Packet Core Gateway (specifically the PGW / EPG running on the SSR or newer Cloud Packet Core platforms) handles traffic using highly optimized ASICs and software worker pipelines. Understanding how the EPG processes TLS extensions helps optimize your F5 configuration.1. How the Ericsson EPG Handles Extension 17516.When the Ericsson EPG is configured for Heuristic TLS Enrichment, its Deep Packet Inspection (DPI) engine scans incoming TCP payloads on port 443.The Insertion Process: The EPG searches for the TLS ClientHello record header. It calculates the extension array offsets, dynamically shifts the remaining TLS bytes downstream, and injects Extension 17516 (which, as you verified in your packet capture, contains 4 bytes of TLS headers and 16 bytes of data).The Fragmentation Threshold: EPG platforms enforce strict MTU boundaries. If a subscriber's initial ClientHello packet is already 1,445 bytes, adding the 20-byte extension pushes it to 1,465 bytes. The EPG's internal network stack will instantly transmit the first 1,460 bytes and create a second TCP fragment for the remaining 5 bytes."
- 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
- Stan_PIRON_F5
Employee
So the last version is working to:
- extract and remove attribute 17516 from client side CLIENT_HELLO before BigIP TLS catches the packet (to make the packet RFC compliant because the incoming packet was not)
- insert in on server side CLIENT_HELLO with full TLS RFC compliance
The previous rule was doing the same, the only change I made was to convert signed integer to unsigned, which may not solve the issue but prevent infinite loop if a malformed packet was sent.
- 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 } - 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?
- 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] }
- kazeem_yusuf1
Nimbostratus
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