Mar 27, 2026 - For details about updated CVE-2025-53521 (BIG-IP APM vulnerability), refer to K000156741.

Forum Discussion

kuroki's avatar
kuroki
Icon for Altostratus rankAltostratus
Apr 30, 2026

SSL Forward Proxy, iRules and Client Hello

Hi all, I am seeing odd behaviour using SSL fwd proxy (SSLO):

My intention is to use the client hello (SNI) to influence SSSL profile selection. I have 2 SSSL profiles setup, let call them A and B

For trusted connections (i.e. certs issuers in SSSL CA bundle) is am unable to extract the SNI from the initial CH, using the CLIENTSSL_CLIENTHELLO event and [SSL::extensions -type 0]. These are send to profile A based on SNI.

I have pcaps showing the CH incoming to the F5. I assume this may have something to do with the 'verified handshake' functionality. It appears the test client browser keeps attempting connection and I see inconsistent results (some connections are reset, some succeed). In irule logs its apparent the SNI does eventually become available in the CLIENTSSL_CLIENTHELLO event.

For untrusted/self signed etc this doesn't appear to happen, these are sent to Profile B (identical to A for testing purposes) so my assumption is the F5 is doing some kind of SNI processing (compare to CN's in trust store?) and then connecting to the server for 'verified handshake' before releasing the SNI into the CLIENTSSL_CLIENTHELLO event?

I have seen an iRule that effectively disables SSL then parses the raw client hello for SNI, I expect this may work as it would intercept the raw CH so the F5 cannot interfere or do any server-side preamble, but I'd rather do this within the realms of defined events if possible... :-)

 

Any suggestions or comments welcome! thanks

2 Replies

    • kuroki's avatar
      kuroki
      Icon for Altostratus rankAltostratus
      May 11, 2026

      Hi Kevin, yes it's SSLO. The server profiles are the SSLO created one (A) + child profile (B).

      I have tried a different tact.. moving the initial SNI extraction to LTM policies, and I have been able to intercept the CH reliably using LTM policies, pushing it into a variable and using that in the iRule, but I still get connection resets.

      It appears the browser(s) (edge/chrome) do not resend SNI for subsequent requests to the same page, perhaps because they are using a different client src port they are not persisting to the original SNI sessions 'mapping' to the correct SSSL profile, the handshake fails occur on sessions from different client src ports than the initial CH/SNI.

      The first connection works fine, e.g. open browser > enter URI > web page returned OK.

      Subsequently refreshing that same site is what triggers the HS fail/connection reset.

       

      A gap in my understanding is how the F5 would handle this behaviour when using the SNI option in the profile (which is not an option as the pattern matching is very limited e.g. to only matching to a single depth in the SNI e.g. server name id *.domain.com would only match test.domain.com not host.test.domain.com :-(

      If there was an iRule equivalent to the built in SNI matching functionality, but with better pattern matching (or at least wildcarding) that could work, or a way to normalise SNI information somehow before it reaches that logic decision in the SSSL selection?