Forum Discussion

Kevin_Pruett_73's avatar
Kevin_Pruett_73
Icon for Nimbostratus rankNimbostratus
Dec 31, 2012

ssl::ciper iRule, working.....kinda......

We have deployed an iRule using the SSL:cipher keyword and are getting mixed results. The scenario is as follows:

 

We are supporting a vendor software that is sending both ssl encrypted and unencrypted traffic to the same non-standard port. The vendor has requested that when an unencrypted packet comes in (HTTP in the header), that it be redirected to HTTPS. After looking through DevCentral, I found the below iRule and modified it slightly (THANK YOU to the original poster of this, by the way!) to remove the HTTP::port keyword to accomodate the fact that the configuration file for the vendor application hard codes the port into the rule.

 

 

Check if the client used an SSL cipher

 

if {not ([catch {SSL::cipher version} result]) && [string tolower $result] ne "none"}{

 

Client did use a cipher

 

log local0. "\$result: $result. Allowing encrypted request."

 

 

} else {

 

Client did not use a cipher

 

log local0. "\$result: $result. Redirecting unencrypted request."

 

HTTP::redirect ]

 

log local0. "[HTTP::host][HTTP::uri]"

 

}

 

}

 

What we are getting is some strange behavior. When the user tries to use parts of the application that trigger this iRule, initially it sits and spins, but if you click off of the active application window and click back on it, it succeeds. This behavior is also inconsistent. Sometimes the application just fails. I am curious if this could be because the traffic will pass through this iRule twice since the encrypted and unencrypted port are the same.

 

Is this something anyone has seen or had to troubleshoot before, and can you provide any assistance?

 

Thank you,

 

Kevin Pruett

 

 

 

 

application delivery
dev
devops
iRules

13 Replies

Sort By
  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Dec 31, 2012
    Shouldn't your redirect also be specifying the non-standard port like so: https://[HTTP::host]:XX[HTTP::uri]
  • Kevin_Pruett_73's avatar
    Kevin_Pruett_73
    Icon for Nimbostratus rankNimbostratus
    Dec 31, 2012

    Thank you for the quick reply! I originally had that in place, but the output on wireshark showed two iterations of the non-standard port, ie , when this was in place. I believe this is because of the way the vendor code is written.

     

  • Kevin_Pruett_73's avatar
    Kevin_Pruett_73
    Icon for Nimbostratus rankNimbostratus
    Dec 31, 2012
    OOPS....missed that on the cut and paste....thank you for your assistance, BTW:

     

     

    when HTTP_REQUEST
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 31, 2012

    The app shouldn't receive a request which the iRule is redirecting, so I'm not sure where the double port is coming from.

    Can you enable logging, retest and reply with the sanitized logs from /var/log/ltm?

    Also, which LTM version are you running?

    
when HTTP_REQUEST {

    Check if the client used an SSL cipher
   if {not ([catch {SSL::cipher version} result]) && [string tolower $result] ne "none"}{

       Client did use a cipher
      log local0. "\$result: $result. Allowing encrypted request to [HTTP::host][HTTP::uri]"
 
   } else {

       Client did not use a cipher
      log local0. "\$result: $result. Redirecting unencrypted request to https://[HTTP::host]:1234[HTTP::uri]"
      HTTP::redirect "https://[HTTP::host]:1234[HTTP::uri]"
   }
}

    Aaron

  • Kevin_Pruett_73's avatar
    Kevin_Pruett_73
    Icon for Nimbostratus rankNimbostratus
    Dec 31, 2012
    Aaron,

     

     

    Thanks for the reply. I am currently using 11.1 The double port is coming from the fact that the vendor's configuration file makes the port part of the host before the application sends the request, so the port is part of the host when it arrives. I just received some additional communication from the vendor and have to shift gears. In packet captures, they are using a lot of 302 redirects and have offered the following iRule:

     

     

    when HTTP_REQUEST {

     

    HTTP::respond 302 Location "https://[getfield [HTTP::host] : 1][HTTP::uri]"

     

    }

     

     

    When I applied this iRule it essentially stopped all application function. I really appreciate your response. I am not brand new to iRules, but I am "new-ish". I am working on a possible solution by building in some "IF" logic so please stay tuned. I may be sending up another flare. If by some miracle this works, I will share the finished product for group edification.

     

     

    Thank you again,

     

     

    Kevin Pruett

     

     

  • What_Lies_Bene1's avatar
    What_Lies_Bene1
    Icon for Cirrostratus rankCirrostratus
    Dec 31, 2012

    Is there is a chance the redirects from the server(s) are http:// rather than https://? If that's the case the HTTP Profile setting Redirect Rewrite might be useful to you.

     

  • Kevin_Pruett_73's avatar
    Kevin_Pruett_73
    Icon for Nimbostratus rankNimbostratus
    Dec 31, 2012
    Steve,

     

     

    That is what I am wondering as well. I am working with the end user later today to do some logging and capturing to get a better feel for what we are looking at. We have pretty much resolved that we are trying to patch poor code with F5 function. Feels kind of dirty :)

     

     

    Thank you for all of your (and Aaron's) help and input.

     

     

    Kevin
  • Kevin_Pruett_73's avatar
    Kevin_Pruett_73
    Icon for Nimbostratus rankNimbostratus
    Dec 31, 2012
    Steve,

     

     

    You were correct. The application client was sending an HTTP request and being redirected to an HTTPS URL. Once I set redirect rewrite to all in the custom HTTP profile, all symptoms cleared. Thank you again for your help.

     

     

    Kevin Pruett