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

Dayton_Gray_103's avatar
Dayton_Gray_103
Icon for Nimbostratus rankNimbostratus
Jun 07, 2007

SSL unencrypt/reencrypt after looking at header

Here is my situation.

 

 

We are looking to send SSL (port 443) traffic to different pools based upon host header. and either un-encrypt or re-encrypt based upon pool used. I have not found any solution after digging through the forums.

 

 

Basically we are looking to send 443 traffic to a pool pointing to a different data center (re-encrypted via SSLServer profile) if it does not match a certain host header. If the host header is matched, it needs to send it unencrypted to a local pool (local web servers).

 

 

Is there anyway to do this via iRule? From what I've read I'm not sure that it is possible so we came up with another hair-brained scheme to have 3 virtual servers. The first will un-encrypt (client SSL) and the pool would point to the second Virtual server. The second virtual server would re-encrypt (server SSL) and have an iRule which would look at the host header. If the host header did not match it would send the traffic to the other datacenter and if it did match send to the third Virtual server. The third virtual server would simply un-encrypt (client SSL) and send to the internal web servers.

 

 

Does this sound feasible? I have tested and the BigIP seems to have a problem connecting back to itself (pool pointing to another Virtual Server). I have tried this doing just port 80 traffic and it doesn't seem to work. My guess is that it is having a problem with NAT/SNAT tables. Any suggestions?
application delivery
dev
devops
iRules

17 Replies

Show More
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jun 15, 2007
    I think you need to wrap the condition you're "not'ing" in parens. I threw an extra pair around the first test to be sure.

    
when HTTP_REQUEST {
   set disable 1
   if { (not ([HTTP::uri] starts_with "/exchange/" )) || [HTTP::path] starts_with "/exchweb/" }{
      pool UAT-content
      log local0."test4-1"
   } else {
      set disable 0
      pool OWA-Pool
      log local0."test4-2"
   }
}
when SERVER_CONNECTED {
   if { $disable == 1 }{
      SSL::disable
      log local0."nossl"
   }
}

    Can you test this?

    Aaron
  • Ian_Amos_37833's avatar
    Ian_Amos_37833
    Icon for Nimbostratus rankNimbostratus
    Jun 15, 2007
    I've just been shown what is wrong with the TCL.. The problem is having the 'not' and the || statemnet.. I've swapped things round, and now the "/exchange/" part is working!

     

     

    Problem now is that the "when SERVER_CONNECTED" part isn't disabling the SSL like I want it to..

     

     

    How can get the rule to turn off SSL serverside?
  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jun 15, 2007
    I had a logic error with where I put the parens. This might be a bit more clear:

    
when HTTP_REQUEST {
   
   if { [HTTP::path] starts_with "/exchange/" ) || [HTTP::path] starts_with "/exchweb/" }{
      set disable 0
      pool OWA-Pool
      log local0. "test4-2"
   } else {
      set disable 1
      pool UAT-content
      log local0. "test4-1"
   }
}
when SERVER_CONNECTED {
   if { $disable == 1 }{
      SSL::disable
      log local0. "nossl"
   }
}

    When a request should have SSL disabled, do you see nossl being logged? Are the packets going to the node(s) in the test4-1 pool still encrypted? Also, what version of BIG-IP are you running?

    Aaron
  • Dayton_Gray_103's avatar
    Dayton_Gray_103
    Icon for Nimbostratus rankNimbostratus
    Jun 15, 2007
    I received confirmation from F5 that this will NOT work in 9.4. For now I think I am going to stick with 9.2/9.3 as it seems we may break iRules by upgrading. F5 has recommended the below:

     

     

    "In 9.4.x you can redirect from virtual server A to virtual server B, so what you'll do is evaluate the header, and if you want to send the traffic to the pool that will be ssl encrypted, redirect it to another virtual server, which has that pool assigned.

     

     

    Check with DevCentral for the fine details, but basically, in 9.4.x you can use "virtual [name of virtual]" the same way you use "pool [name of pool]""

     

     

    Byzandula

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Jun 18, 2007
    Hi Byzandula,

     

     

    Can you elaborate on what Support told you? Were you trying something more complicated than selectively disabling server SSL like what you had listed in this thread?

     

     

    I've successfully tested a rule using SSL::disable on 9.4 with a standard virtual server and with ASM. I'm not sure whether it's true across the board that using SSL::disable in the SERVER_CONNECTED event won't work.

     

     

    Thanks for any info you can provide,

     

    Aaron
  • Dayton_Gray_103's avatar
    Dayton_Gray_103
    Icon for Nimbostratus rankNimbostratus
    Oct 03, 2007
    hoolio,

    I'm still looking at solutions to this. F5 did not give any additional information. I think I am going to open a ticket and see how far that gets me. I need to get the below working with 9.4. I'm not thrilled to have to create new virtual servers to handle this as it will add a great deal of clutter and complexity. Have you made any progress with this?

    
when HTTP_REQUEST {
   if { [HTTP::header Host] == "xxx.xxxprd1.xxx.com" or [HTTP::header Host] == "xxx1.xxxprd1.int.xxx.com" }
  {
    set reencrypt 0
    HTTP::header remove "X-Forwarded-For"
    HTTP::header insert "ProxyHTTPS" "true"
    pool xxx_xxx
  } else {
    set reencrypt 1
    pool xxx1_xxx
  }
}
when SERVER_CONNECTED {
  if { $reencrypt == 0 }{
    SSL::disable
  }
}
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Oct 04, 2007
    You're very welcome.

     

     

    We do have a very serious push internally to improve iRule documentation, and it's starting to gain momentum, so we should be doing better as time goes on. That said, this precise issue (CR83395) is documented in the 9.4.2 release notes.