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

Nice work, thanks for sharing! Regarding the variable checking, you can use the catch command (Click here), or you can use info exists varName.

Very nice indeed Lupo, thanks for sharing!
Don.

replace TCP::close command with reject in code above to avoid core dumps

Hi,
This rule only partially works. Our Web servers are scanned by several PCI DSS scanners & they all report that our LTM load balanced servers support SSL renegotiation with the rule applied. You can test this at:
http://netsekure.org/2009/11/tls-renegotiation-test/
Any thoughts on why its not working correctly ?

Two thoughts from my side:

1. While http://netsekure.org/2009/11/tls-renegotiation-test/ reports Connecting to xxx:443 Sending partial HTTP request Trying to renegotiate Site allows client initiated renegotiation! Unpatched servers allowing client initiated renegotitation are vulnerable to a variation of the TLS MiTM attack. HTTP Response: HTTP/1.1 200 OK Date: Thu, 22 Apr 2010 08:31:30 GMT [...]I see no actual renegotiation taking place when investigating a packet dump of that connection:No. Time Source Destination Protocol Info 4 0.114197 205.205.221.5 x.x.x.x SSLv2 Client Hello 5 0.114211 x.x.x.x 205.205.221.5 TLSv1 Server Hello, 6 0.114219 x.x.x.x 205.205.221.5 TLSv1 Certificate, Server Hello Done 8 0.231424 205.205.221.5 x.x.x.x TLSv1 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 9 0.232253 x.x.x.x 205.205.221.5 TLSv1 Change Cipher Spec, Encrypted Handshake Message 10 0.345634 205.205.221.5 x.x.x.x TLSv1 Application Data (38 bytes) 12 3.357203 205.205.221.5 x.x.x.x TLSv1 Application Data (42 bytes) 14 3.570393 205.205.221.5 x.x.x.x TLSv1 Application Data (23 bytes) 15 3.611217 x.x.x.x 205.205.221.5 TLSv1 Application Data (391 bytes) 19 3.727658 205.205.221.5 x.x.x.x TLSv1 Encrypted Alert (I stripped 0-byte ACK and TCP handshake packets)
   It looks like that check isn't working properly to me.
   Have you been able to get a negative result on renegotiation for some other site at all? I couldn't find one.
2. My iRule does not prevent renegotiations, but it closes the connection after one occurred. Thus a scanner will be able to successfully perform a TLS renegotiation, but will not be able to send data to the virtual server ressource.

Perhaps you should perform a packet dump and investigate your webserver logs for the request actually reaching the server.

I still think the iRule reliably prevents abuse of the TLS design problem.

Hi,
There are some sites I've found that pass the test (www.asos.com), but my PCI DSS scanning supplier says I accept the http request, therefore I am vulnerable.
Looks like I have to upgrade (currently 9.3.0).

Hi,
The following article describes a method to test client initiated SSL renegotiation.

http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html

The iRule behaviour appears to reset as soon as the certificate has been re-verified.

Our PCI DSS scanning supplier is rescanning our network now with the iRule in place. I will let you know if the iRule satisfies the requirement.

We are running BIG-IP v 9.4.5.

We didn't pass the PCI DSS scanning with BIG-IP v 9.4.5 and the iRule for this version.

We updated to BIG-IP v 9.4.8 HF3 and the iRule for this version. The behaviour is the same as observed on http://blog.ivanristic.com/2009/12/testing-for-ssl-renegotiation.html

I will let you know if BIG-IP v 9.4.8 HF3 passes the PCI scanning this time.

9.4.8 HF3 failed as well using the iRule.

Does anyone have suggestions?

Any rule you have *must* prevent renegotiation. If you have completed the renegotiation, the attack has already been successful, at least against the HTTP protocol. The reason is that the server buffers the client request, which is malicious coming from the man-in-the-middle (MiTM). Once renegotiation completes, the server executes the buffered request, which means game over.

So to be truly protected, you need to drop the actual renegotiation attempt. This is why netsekure.org reports you are vulnerable.

Is this still the recommended way to mitigate this vulnerability at the BigIP level?

Patching our web servers is an unsavory option at this point.

F5 has provided a config option in the client SSL profile, called "Renegotiation" to prevent renegotiation by default:

SOL10737: SSL Renegotiation vulnerability - CVE-2009-3555 / VU#120541
http://support.f5.com/kb/en-us/solutions/public/10000/700/sol10737.html

BIG-IP 10.1.0, BIG-IP 10.2.0
Introduce a clientssl / serverssl profile option to control whether midstream SSL renegotiation is allowed. For versions which include this CR, the default setting for the clientssl profile is disabled, and the default setting for the serverssl profile is enabled.

Aaron

Thanks for the quick follow-up hoolio.