Forum Discussion

kazeem_yusuf1's avatar
kazeem_yusuf1
Icon for Nimbostratus rankNimbostratus
Aug 01, 2018

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

  • Hum ok....DO you have a summary of what you have propose and the purpose please in order to understand

     

    • Stan_PIRON_F5's avatar
      Stan_PIRON_F5
      Icon for Employee rankEmployee

      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's avatar
        Kazeem_Yusuf
        Icon for Nimbostratus rankNimbostratus

        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."

      • Stan_PIRON_F5's avatar
        Stan_PIRON_F5
        Icon for Employee rankEmployee

        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.

  • 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
    }
    

     

  • 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?

     

  • 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] }