Forum Discussion
iRule not being processed fully
We are testing and trying to hammer out an iRule that will take traffic for a specific URL/host [host3.example.com] and have it go to a weaker SSL Profile than is currently being used by the Virtual Server. The iRule seems to be partially processed when we examine the logs.
iRule:
when HTTP_REQUEST {
if { [HTTP::host] equals "cdn.alpha.dev.insidesales.com" } {
log local0. "client [IP::client_addr]:[TCP::client_port] uri [HTTP::uri]"
SSL::session invalidate
set cmd "SSL::profile /Common/IS-Alpha_Weak"
eval $cmd
SSL::renegotiate
event disable all
}
}
This is to allow older browsers/OSs to establish a "secure" connection using TLSv1.0, SSLv2, or SSLv3. We are using Windows XP and IE8 to test and verify.
When testing the weaker OS and browser it fails to process the iRule and the log [/var/log/ltm] shows:
Oct 9 14:29:03 F5-VE info tmm2[15974]: 01260013:6: SSL Handshake failed for TCP x.x.x.x:1437 -> y.y.y.y:443 Oct 9 14:29:03 F5-VE info tmm1[15974]: 01260013:6: SSL Handshake failed for TCP x.x.x.x:1437 -> y.y.y.y:443
However, when testing with a current OS & browser the page is displayed, but the log shows:
Oct 9 14:30:07 F5-VE info tmm[15974]: Rule /Common/Weak_Security_Profile : client x.x.x.x:1447 uri /favicon.ico
Running Qualys scans against the host shows it is using the strict SSL Profile that is specified in the Virtual Server config rather than processing the iRule and directing traffic for the host through the weaker SSL Profile specified in the iRule.
We are testing this on our Dev F5 VE which is running 12.1.2.
- Lee_Sutcliffe
Nacreous
Can the weaker OS support the ciphers in client SSL profile on the VS?
If not you could have your' VS configured for a weaker cipher as it will need to process the initial SSL handshake. Then renegotiate for stronger ciphers
Hi jmgrange,
the short answer to get an A+ Qualys rating while maintaining support for Windows XP can be found here...
The long answer to your question is...
To switch and renegotiate from a high secure to a low secure Client-SSL-Profile for legacy clients you simply can not utilize the $1 event, because its already too late in the chain...
This a pure matter of "chicken or the egg": A client won't send the HTTP request before it has successfuly negotiated the SSL connection. In contrast you require that the legacy client has already send an HTTP request to become able to renegotiate the SSL connection using legacy SSL chipher settings. So in the end your renegotiation code will never become triggered by those clients who realy depend on it.^^
To still support your requested scenario you would need to identify the client (resp. its supported SSL capabilities) before the SSL handshake starts. But unfortunately this is a somewhat complicated approach and also costs a ton of CPU cycles. If my short answer does not meet your requirements, then you may take a look to Kevin Stewart SSL finger printing article to get an idea how complex this could be...
Cheers, Kai
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com