iRule for redirecting 128bit RC4-md5 and 128bit RC4-SHA to webpage

If you want to block 128bit RC4-md5 & RC4-SHA you can modify the cipher suite in the client SSL profile to something like:

DEFAULT:!RC4-SHA:!RC4-MD5

Which should allow all the default ciphers but also block those two, it's also worth knowing that MD5 ciphers are blocked in the default cipher list in v10.2 and higher.

thank you for the quick reply, however since this VIP is used by most of users, management wanted to redirect them to webpage instead of denying them...also there is 256 bit RC4-md5 is allowed...

If I may add, there are a few concerns:

1. First, the cipher list name should never just be "RC4". If anything it'll be "RC4-SHA" or something that describes at least one encryption and one digital signature algorithm.

    

2. When a client and server negotiate an SSL/TLS session, the client will send a list of supported ciphers, and the server will (usually) pick something from that list. Practically all modern browsers will prefer RC4. It's also not possible, I believe, to do anything other than 128 bit RC4 in any of these browsers.

    

3. As Lapayne already pointed out, the DEFAULT cipher list already excludes MD5, so you should never see that one.

    

So, in lieu of RC4-SHA, what are you trying to get users to use?

How about you specify the ciphers available to be used in the Client SSL profile and exclude that cipher group?

https://support.f5.com/kb/en-us/solutions/public/13000/100/sol13171.html?sr=33336842

As you say, the cipher is decided by the server so you could catch the server response, allow the SSL handshake to continue and when you see an HTTP_REQUEST then redirect it. Does that make sense?

Thank you Kevin, Pete and Lapayane for the quick reply; however when I capture traffic I still see latest chrome, IE, Firefox all includes RC4-MD5. so I had changed iRule to check for RC4-MD5 and RC4-SHA but since cipher suite includes RC4-MD5 every connection is getting redirected to this webpage. Also Pete I have client profile setup as "!LOW !EXP !SSLv2 RSA HIGH MEDIUM"

but if I setup HTTP_REQUEST somehow traffic picks up cipher suite during client request after TCP handshake and during SSL handshake. I always thought HTTP_REQUEST comes after TCP Handshake - SSL Handshake...

An HTTP_REQUEST does in fact come after the TCP and SSL handshakes, and the SSL::cipher command is only going to return the chosen cipher AFTER the SSL handshake, which means the command is only valid in SSL event and above. If you're looking at the SSL handshake in the network capture, you're going to see the client present a list of supported ciphers, one of which will invariably be RC4-MD5. The BIG-IP, however, will never choose that cipher unless you've specifically allowed it in your client SSL profile.

If you're looking to reject any browser that presents RC4-MD5 as a supported cipher, then you're most likely going to reject EVERY browser. I also tested your cipher string, and every browser on a Win7x64 system negotiated RC4-MD5.

Thank you Kevin, sure all of the latest browser does support RC4-md5; but I want to make sure cipher that is used in the communication is other than SSLv3 128bit RC4-md5 and SSLv3 128bit RC4-SHA. So every other cipher like TLSv1 RC4-md5 and TLSv1 RC4-SHA, SSLv3 RSA etc is good.

So like I said in client profile I am blocking only SSLv2, low cipher and allowing anything else....so I wanted to write an iRule that check or maybe at SERVERSSL_SERVERHELLO when it sends cipher that needed to be used for the communication which shouldn't be SSLv3 128bit RC4-md5 or SSLv3 128bit RC4-SHA1....

Hi,

I'm trying to do the same. I'm planning to disable RC4-MD5 and RC4-SHA within the client ssl profile (ALL:!ADH:!SSLv2:!EXPORT40:!EXP:!LOW:!RC4-MD5:!RC4-SHA:@SPEED). I also have SSLv2 disabled. Do you know where I can find a list of browsers that will be affected by this? I heard IE6 will not work if these ciphers are disabled.