Forum Discussion
gdoyle
Cirrostratus
CirrostratusCustom Response Upon Denial with iRule.
We created an irule which denies a user access if they are not using TLS 1.1 or greater (so TLS1.0 or no TLS). We would like a custom message, and although it is in the iRule, that is not the message we receive when we test. Am I missing something simple?
Thanks.
when HTTP_REQUEST {
switch -glob [SSL::cipher version] {
"TLSv1.*" {
Do nothing and allow the request
}
default {
HTTP::respond 200 content \
"Maintenance page
**********CUSTOM DENIAL MESSAGE HERE.**********
" "Content-type" "text/html"
return
}
}
}
26 Replies
cjuniorNacreous
Hi,
I understood that you need to send a response in L7. In my humble opinion, you did a good job. So, if you aren't receiving the message, your connection may be being dropped before being established. Could you check your ciphers in SSL client profile? Anyway, let me do it a little diferent. Respectfully,when HTTP_REQUEST { if { not ([SSL::cipher version] starts_with "TLSv1.") } { HTTP::respond 200 content { Maintenance page **********CUSTOM DENIAL MESSAGE HERE.********** } Content-Type text/html Connection close } }- Yann_Desmarest_
Hello,
The irule below allow you to generate a custom message when the connection use a weak protocol :
when HTTP_REQUEST { switch -glob [SSL::cipher version] { "TLSv1.1" - "TLSv1.2" { Do nothing and allow the request } default { HTTP::respond 200 content \ "<html><head><title>Maintenance page</title></head><body> <p align=center> **********CUSTOM DENIAL MESSAGE HERE.********** </p></body></html>" "Content-type" "text/html" return } } }Tested on my lab with success. Just few commands on the bigip that can help you test :
openssl s_client -connect 172.20.2.7:443 -tls1_1 openssl s_client -connect 172.20.2.7:443 -tls1_2 openssl s_client -connect 172.20.2.7:443 -tls1 openssl s_client -connect 172.20.2.7:443 -ssl3when the ssl connection is established, you can type "GET /" and enter
- cjuniorHi Yann, it's only to register that I can't understand when my code will fail, as it return TLSv1 instead of TLSv1.0. Am I really wrong? Regards, (tested in v.12.0.0 and v11.6.0) log local0. "=== \[SSL::cipher version\]: [SSL::cipher version]" : === [SSL::cipher version]: TLSv1 : === [SSL::cipher version]: TLSv1.1 : === [SSL::cipher version]: TLSv1.2
Yann_DesmarestCirrus
Hello,
The irule below allow you to generate a custom message when the connection use a weak protocol :
when HTTP_REQUEST { switch -glob [SSL::cipher version] { "TLSv1.1" - "TLSv1.2" { Do nothing and allow the request } default { HTTP::respond 200 content \ "<html><head><title>Maintenance page</title></head><body> <p align=center> **********CUSTOM DENIAL MESSAGE HERE.********** </p></body></html>" "Content-type" "text/html" return } } }Tested on my lab with success. Just few commands on the bigip that can help you test :
openssl s_client -connect 172.20.2.7:443 -tls1_1 openssl s_client -connect 172.20.2.7:443 -tls1_2 openssl s_client -connect 172.20.2.7:443 -tls1 openssl s_client -connect 172.20.2.7:443 -ssl3when the ssl connection is established, you can type "GET /" and enter
- cjuniorHi Yann, it's only to register that I can't understand when my code will fail, as it return TLSv1 instead of TLSv1.0. Am I really wrong? Regards, (tested in v.12.0.0 and v11.6.0) log local0. "=== \[SSL::cipher version\]: [SSL::cipher version]" : === [SSL::cipher version]: TLSv1 : === [SSL::cipher version]: TLSv1.1 : === [SSL::cipher version]: TLSv1.2
- cjunior
So, If you try the iRule below, what did you see in the /var/log/ltm file?
when CLIENT_ACCEPTED { log local0. "=== Client 3WHS finished" } when CLIENTSSL_CLIENTHELLO { log local0. "=== Starting SSL negotiation: [SSL::cipher version]" } when CLIENTSSL_HANDSHAKE { log local0. "=== SSL negotiation completed: [SSL::cipher version]" } when HTTP_REQUEST { log local0. "=== HTTP request [SSL::cipher version]" if { not ([SSL::cipher version] starts_with "TLSv1.") } { log local0. "=== Current request blocked for SSL: [SSL::cipher version]" HTTP::respond 200 content { Maintenance page **********CUSTOM DENIAL MESSAGE HERE.********** } Content-Type text/html Connection close } } when HTTP_RESPONSE { log local0. "=== HTTP replied and flow OK" }Please, check your /var/log/ltm file: e.g.
cat /var/log/ltmMay 20 17:47:19 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Client 3WHS finished May 20 17:47:19 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Starting SSL negotiation: TLSv1.2 May 20 17:47:19 bigiplab info tmm3[18141]: Rule /Common/rule_https : === SSL negotiation completed: TLSv1.2 May 20 17:47:24 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Begin HTTP request TLSv1.2 May 20 17:47:24 bigiplab info tmm3[18141]: Rule /Common/rule_https : === HTTP replied and OK May 20 17:47:30 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Client 3WHS finished May 20 17:47:30 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Starting SSL negotiation: TLSv1 May 20 17:47:30 bigiplab info tmm3[18141]: Rule /Common/rule_https : === SSL negotiation completed: TLSv1 May 20 17:47:33 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Begin HTTP request TLSv1 May 20 17:47:33 bigiplab info tmm3[18141]: Rule /Common/rule_https : === Current request blocked for SSL: TLSv1 May 20 18:01:49 bigiplab info tmm[18141]: Rule /Common/rule_https : === Client 3WHS finished May 20 18:01:49 bigiplab info tmm[18141]: Rule /Common/rule_https : === Starting SSL negotiation: SSLv3 May 20 18:01:49 bigiplab info tmm[18141]: Rule /Common/rule_https : === SSL negotiation completed: SSLv3 May 20 18:01:53 bigiplab info tmm[18141]: Rule /Common/rule_https : === HTTP request SSLv3 May 20 18:01:53 bigiplab info tmm[18141]: Rule /Common/rule_https : === Current request blocked for SSL: SSLv3We're almost there, don't give up!
Best Regards. 
gdoyleThe only conclusion that seems to make sense to my team is what seems to be the consensus here: The connection is being denied prior to the iRule being offered, so the browsers are returning whatever their default message is for being denied by TLS.
With that said, would it be possible to use something like an iFile that returns the specific message if the user is not using a better encryption than TLS1.0?
The main goal is to deny TLS1.0, but we also need to give the customer a message with the proper reasoning or our Help Desk will be flooded with calls.
- Yann_Desmarest_
Hi,
You can use one of the irules provided above and add TLS1.0 ciphers in the cipher list. For example, you can do the following in the cipher list of your client ssl profile :
DEFAULT:TLSv1- gdoyleI added that cipher and then tried each of the irules listed above, but I am at the same result.
- Yann_Desmarest_Hi, can you explain the behavior ? I tested the same configuration on my lab in multiples versions and everything work as expected
- gdoyleThe TLSv1 in the cipher and using any of the irules that y'all were kind enough to provide above, I receive the same message. Firefox tells the testers that the website owner has configured the site improperly. IE says that in order to access the site they will have to enable TLS 1.0, 1.1, or 1.2. It is basically acting as if no irule exists at all and immediately being denied and receiving the default message from the browser. This is even with TLS1 allowed in the ciphers and the irule in place.. It is odd. I'm wondering now if there is just another way, via ifile or something else, to go about doing this check and redirecting them to a notification page? Thoughts?
- Yann_Desmarest
Hi,
You can use one of the irules provided above and add TLS1.0 ciphers in the cipher list. For example, you can do the following in the cipher list of your client ssl profile :
DEFAULT:TLSv1- gdoyleI added that cipher and then tried each of the irules listed above, but I am at the same result.
- Yann_DesmarestHi, can you explain the behavior ? I tested the same configuration on my lab in multiples versions and everything work as expected
- gdoyleThe TLSv1 in the cipher and using any of the irules that y'all were kind enough to provide above, I receive the same message. Firefox tells the testers that the website owner has configured the site improperly. IE says that in order to access the site they will have to enable TLS 1.0, 1.1, or 1.2. It is basically acting as if no irule exists at all and immediately being denied and receiving the default message from the browser. This is even with TLS1 allowed in the ciphers and the irule in place.. It is odd. I'm wondering now if there is just another way, via ifile or something else, to go about doing this check and redirecting them to a notification page? Thoughts?
- gdoyle
I'm not sure exactly how to code for ifiles... (Or irules, to be fair), but would something like this work?
when HTTP_REQUEST { if { not ([SSL::cipher version] starts_with "TLSv1.") } { ifile get } Content-Type text/html Connection close } } - Yann_Desmarest
Hi,
You can try this :
when HTTP_REQUEST { if { not ([SSL::cipher version] starts_with "TLSv1.") } { HTTP::respond 200 content [ifile get message.html] noserver "Content-Type" "text/html" "Cache-Control" "no-cache, must-revalidate" Connection Close } }- gdoyleI tried what you suggested, but the connection does not get denied. Instead of goes right to the page as if TLS1.0 is allowed. This is supposed to happen, except it should be redirected to the custom message page. Is something missing from that rule that would redirect it to the ifile or that would fail to call the ifile?
- Yann_DesmarestHi, the irule is correct. I validated it on my lab. I think that you negociate TLS1.1 or TLS1.2 instead of TLS1.0 for testing
- Yann_Desmarest_
Hi,
You can try this :
when HTTP_REQUEST { if { not ([SSL::cipher version] starts_with "TLSv1.") } { HTTP::respond 200 content [ifile get message.html] noserver "Content-Type" "text/html" "Cache-Control" "no-cache, must-revalidate" Connection Close } }- gdoyleI tried what you suggested, but the connection does not get denied. Instead of goes right to the page as if TLS1.0 is allowed. This is supposed to happen, except it should be redirected to the custom message page. Is something missing from that rule that would redirect it to the ifile or that would fail to call the ifile?
- Yann_Desmarest_Hi, the irule is correct. I validated it on my lab. I think that you negociate TLS1.1 or TLS1.2 instead of TLS1.0 for testing
