mitigating the TLS client-initiated renegotiation MITM attack

I thought I'd share the iRule we use to mitigate one of the recently disclosed TLS attacks. Our focus lies on preventing the possible malicious data insertion during 'client-initiated renegotiation'.

Take care though to check that your virtual server does _not_ depend on (benign) renegotiations. If you're not sure, you can use

bigpipe profile clientssl all show all | grep -e PROFILE -e mid-stream

after a number of friendly connections to check for any 'mid-stream' handshakes.

Now for the iRule:

when CLIENT_ACCEPTED { 
    initialize TLS/SSL handshake count for this connection 
   set sslhandshakecount 0 
 } 
  
  if you have lower priority iRules on the CLIENTSSL_HANDSHAKE event, you have to make sure, that they don't interfere with this iRule 
 when CLIENTSSL_HANDSHAKE priority 100 { 
    a handshake just occurred 
   incr sslhandshakecount 
  
    is this the first handshake in this connection? 
   if { $sslhandshakecount != 1 } { 
      log (rate limited) the event (to /var/log/tmm) 
     log "\[VS [virtual] client [IP::client_addr]:[TCP::client_port]\]: TLS/SSL renegotiation occurred, dropping connection" 
      close the clientside connection 
     TCP::close 
   } 
 }

On initial deployment the rule may fail in the CLIENTSSL_HANDSHAKE event a few times on busy virtual servers. This isn't a problem in our setup, but I welcome suggestions on how to prevent that. Is there a way to check the existance of a variable without inviting an error?

This rule was tested with v9.4.8, should be CMP compatible, and is safe for deployment on multiple virtual servers (i.e. not affected by CR127411). Observed performance impact is minimal.

References on the vulnerability:

http://extendedsubset.com/?p=8

http://www.links.org/?p=780

http://www.ietf.org/mail-archive/web/tls/current/msg03928.html