Forum Discussion

jmgrange_337011's avatar
jmgrange_337011
Icon for Nimbostratus rankNimbostratus
Oct 09, 2017

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.

application delivery
BIG-IP
iRules
security

2 Replies

Sort By
  • Lee_Sutcliffe's avatar
    Lee_Sutcliffe
    Icon for Nacreous rankNacreous
    Oct 10, 2017

    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

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Oct 10, 2017

    Hi jmgrange,

    the short answer to get an A+ Qualys rating while maintaining support for Windows XP can be found here...

    https://devcentral.f5.com/questions/howto-getting-an-awesome-qualys-ssl-labs-rating-feb-2017-update-51489

    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...

    https://devcentral.f5.com/articles/tls-fingerprinting-a-method-for-identifying-a-tls-client-without-decrypting-24598

    Cheers, Kai