SSL Renegotiation DOS iRule - Updates

There’s been a lot of commentary on the previous post (SSL Renegotiation DOS – an iRule Countermeasure). Here are some of the updates and corrections.

After the previous post went live, Jorge Orchilles called me with a clarification. According to Jorge, the French group “Hacker’s Choice” posted their proof-of-concept tool prior to his posting to the IETF working group, not after. In fact, he said “THC released it in February: http://www.thc.org/thc-ssl-dos/ which is what initiated my research into it.”
According to Jorge’s blog (SSL Renegotiation DOS), other vendors have reported seeing this attack in the wild for over a year now.
Recently one of our customers expressed to us that they are experiencing an SSL-related distributed attack.

This means that the attack is less theoretical than the previous post made it sound.

The iRule has received some scrutiny as well. Jason Rahm had crafted a neat little algorithm that made interesting use of random numbers (as a lookup key) and tables (to keep a sliding window). With an eye toward optimizing both CPU usage and per-flow memory, here is a version of the iRule that:

Uses the normal flow context instead of a random key.
Does away with the table and subtable, saving some memory.
Adds a log message (leave in or take out at your pleasure).

Thanks again go out to the DevCentral community, not only for helping with this iRule, but also for spreading the word (DevCentral Podast) about SSL attacks and our ability to very quickly deploy countermeasures like these.

when RULE_INIT {
    set static::maxquery 5
    set static::mseconds 60000
}
when CLIENT_ACCEPTED {
    set ssl_hs_reqs 0
}
when CLIENTSSL_HANDSHAKE {
    incr ssl_hs_reqs
    after $static::mseconds { if {$ssl_hs_reqs > 0} {incr ssl_hs_reqs -1} }
    if { $ssl_hs_reqs > $static::maxquery } {
        after 5000
        log "Handshake attack detected, dropping [IP::client_addr]:[TCP::client_port]"
        drop
    }
}