For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Mike757's avatar
Mike757
Icon for MVP rankMVP
Feb 11, 2023
Solved

behavior of SSL::disable serverside

Hello! I've configured an https virtual server, with an associated iRule that chooses the server pool according to the URI. The only unusual thing is that some of the pools have SSL servers and o...
application delivery
LTM iRule SSL
  • xuwen's avatar
    xuwen
    Feb 11, 2023

    Better give the config of list ltm virtual xxx and serverside tcpdump to watch whether F5 send clienthello to this pool member

    modify this iRules to test:

     

     

    when HTTP_REQUEST {
  set usessl 0
  switch -glob [string tolower [HTTP::uri]] {
    "/path1/*" {
        set usessl 1
        pool POOL-path1
        persist cookie insert cookie1
    }
    "/path2/*" {
        set usessl 1
        pool POOL-path2
        persist cookie insert cookie2
    }
    "/path3/*" {
        set usessl 0
        # SSL::disable serverside
        pool POOL-path3
    }
    default {
     set usessl 1
    }
 }
}
when SERVER_CONNECTED {
  log local0. "usessl value is $usessl"
  if { $usessl == 0 } {
    SSL::disable
  }
}

     

     

     

Mike757's avatar
Mike757
Icon for MVP rankMVP
Feb 11, 2023

xuwen, you're the man!

Improved iRule worked like a charm. And yes, before the changes I saw the attempt of SSL handshake with the server.

/Mike

xuwen's avatar
xuwen
Icon for Cumulonimbus rankCumulonimbus
Feb 11, 2023

Because SSL:: disable describes that it will send an ssl alert message to the peer, and I'm not sure because I did not experiment with VE. 

In short, iRules Home should simply describe the scope of use of the function, and BIGIP VE should do the experiment for the specific details. In the previous few days [TCP:: option get 28], someone directly copied the example Code displayed by CLIENT_ACCEPTED event, cause [string length [TCP::option get 28] value is 0,  Let Akamai capture packets. Akamai truely carry the tcp option 28 field, Finally, take VE to test and find that this situation should be CLIENT_DATA event use [TCP::option get 28] and not in CLIENT_ACCEPTED event

iRules Event flow order display SSL::disable should be in CLIENT_ACCEPTED or SERVER_CONNECTED event

Here is the link to the iRule Events flow order

https://clouddocs.f5.com/training/community/irules/html/class1/module1/iRuleEventsFlowHTTPS.html