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