iRule: Useful DevCentral Sample for PCI Compliance Assessment
A while ago, I came across an iRule on the F5 DevCentral site called Redirect on Weak Encryption (login required) and wondered what practical purpose it would have since weak ciphers are evil and need to be eradicated. Well, if you have a B2B site that's been around for years, your site's "users" are actually other computers and management wants to know what is going to be impacted by disabling weak encryption BEFORE making the change, then this irule is comes in handy.
If you are running Microsoft's IIS, you can enable schannel logging by toggling a pre-existing registry key. This Knowledge Base article has all the steps necessary to do this. Enabling it, though, will leave your heart heavy because you need to enable the most verbose level of logging to get the cipher and if your site is even moderately busy, your event log will be huge. Another thing missing from the schannel logging output is the client IP address so you'll know something visited your site with export grade encryption but that's about it.
Apache has an edge over IIS here because you can add the
It's for these reasons that this particular irule has suddenly become pretty useful for me. All I need to do is define a second instance of the web site in question, set up a second pool in the BigIP, and route all encryption below 128-bit to the second web site instance. I don't need to know what cipher was used—I just need to know that a weak cipher was used. Now I have a solution that is web server neutral and the result being a (hopefully) smaller web server log file containing all the IP addresses of users employing weak SSL encryption. Below is my slightly modified version of the Redirect on Weak Encryption irule:
If you are running Microsoft's IIS, you can enable schannel logging by toggling a pre-existing registry key. This Knowledge Base article has all the steps necessary to do this. Enabling it, though, will leave your heart heavy because you need to enable the most verbose level of logging to get the cipher and if your site is even moderately busy, your event log will be huge. Another thing missing from the schannel logging output is the client IP address so you'll know something visited your site with export grade encryption but that's about it.
Apache has an edge over IIS here because you can add the
%{SSL_PROTOCOL}x
and %{SSL_CIPHER}x
values to your access log's LogFormat and then write some script to extract the IPs from the logs where SSL_PROTOCOL = SSL2 or SSL_CIPHER = Some Weak Cipher. The only real downside to this approach is that you need a solid understanding of all the ciphers available to OpenSSL that would be considered weak. Once you get that understanding of which ciphers are weak, you won't necessarily need to use that knowledge again once your script is working.It's for these reasons that this particular irule has suddenly become pretty useful for me. All I need to do is define a second instance of the web site in question, set up a second pool in the BigIP, and route all encryption below 128-bit to the second web site instance. I don't need to know what cipher was used—I just need to know that a weak cipher was used. Now I have a solution that is web server neutral and the result being a (hopefully) smaller web server log file containing all the IP addresses of users employing weak SSL encryption. Below is my slightly modified version of the Redirect on Weak Encryption irule:
when HTTP_REQUEST {
set default_pool [LB::server pool]
# check for at least 128 bits of encryption
if { [SSL::cipher bits] < 128 }{
pool weak_pool
} else {
pool $default_pool
}
}