Forum Discussion
Nimbostratusssl::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
13 Replies
What_Lies_Bene1Cirrostratus
Shouldn't your redirect also be specifying the non-standard port like so: https://[HTTP::host]:XX[HTTP::uri]
Kevin_Pruett_73Thank 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.
- What_Lies_Bene1OK, makes sense. What event is this iRule used with?
- Kevin_Pruett_73OOPS....missed that on the cut and paste....thank you for your assistance, BTW:
when HTTP_REQUEST 
hoolioThe 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?
Aaronwhen 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]" } }- Kevin_Pruett_73Aaron,
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
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_73Steve,
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 - What_Lies_Bene1You're welcome Kevin. Good luck.
- Kevin_Pruett_73Steve,
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
