verifying ssl encryption

Sure this is possible. In fact, there's a sample over in CodeShare (Click here) titled

[iRule 9.0] Redirect on weak encryption

Here's how you can do it.

when HTTP_REQUEST { 
    get encryption strength 
   set strength [SSL::cipher bits] 
   if { $strength >= 128 } { 
     pool web_servers 
   } else { 
      Now use one of the destination commands 
      Either specify a pool 
     pool sorry_servers 
      or to a specific node 
     node 10.10.10.10 
      or redirect to a specific URL 
     HTTP::redirect http://some_address/sorry.html 
   } 
 }

Do you have to do this via iRule? Is there any way to reject lower than 128bit encryption in the SSL profile setting?

 

 

Thanks!

Sure, you can do this with the cipher spec on the client SSL profile as described in SOL7815 (Click here). However, Joe's suggestion of an iRule is a more graceful way of letting the client know why they can't access the VIP.

 

 

Aaron

I know this is an old thread, but I have a specific question about it. I setup a test with a tool called THCSSLCheck. It basically lists the ciphers that the server supports. This is similar to when the site is scanned by our infosec folks and they report to us that a site supports keys less than 128 bits. The issue is that I created an iRule to redirect users to apage to tell them why we are rejecting the session. It appears that the SSL session must already be established as even with this iRule, the scanner still shows us accepting the weak keys. Is it possible to have an iRUle look at the cipher bits and not complete the SSL session if the cipher is not at least 128 bits. Note that the iRule works just fine and the redirect works, but I will still end up getting scanner results that show it supported. Note that is I reject the connection in CLIENTSSL_HANDSHAKE I get the same behavior as if I disabled the weak ciphers in the profile. I guess I want it both ways in that I want to reject the SSL session but I also want to send a redirect.

 

 

Thanks for you consideration

 

 

Tom

Hi Tom,

 

 

It's a 'one or the other' situation. If you want to pass the pentest check you need to disallow the cipher in the SSL profile or using an iRule to prevent the SSL handshake from completing. Doing so prevents you from completing the handshake and sending an HTTP response to clients with a low cipher.

 

 

I think the former option is a bad one because it blocks clients from accessing the VIP with no indication of why. So they just see a 'page cannot be displayed' error in the browser and assume the site is down. Completing the handshake with a low cipher and sending an HTTP response indicating the client must upgrade their browser to use the site is much better for user experience. And it's not a security issue because any client trying to use a low cipher won't be able to access the app. It's just a reporting issue because a pen test will give a false positive.

 

 

Aaron

Aaron,

 

 

I agree. I tried it all ways: iRule in HTTP_REQUEST, iRule in CLIENTSSL_HANDSHAKE, and on the profile.

 

If I check the cipher strength in CLIENTSSL_HANDSHAKE and reject the request if the bits are < 128, this handles the scanners OK, but I still cannot do the redirect.

 

 

I was thinking that I could just send a reply on the wire that looked like an HTTP response, but as the client has not made an HTTP request, there is no way to handle that. I did just tell our security team that this is the way it is. They can verify that we do not allow the traffic with a lower strength cipher, and chalk the rest up to a false positive.

 

 

Note I do like the fact while the docs for the CLIENTSSL_HANDSKARE state this event is fired when the SSL connection is done, if you reject in there, you actually do stop the processing. So, it is really "The CLIENTSSL_HANDSHAKE event is called as the last step of session negotiation". If this event does not complete processing, the SSL session is terminated. The docs stating that this is when it is finished was a bit misleading.

 

Thanks,

 

 

Tom