Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Answers

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
0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Nice work, thanks for sharing! Regarding the variable checking, you can use the catch command (Click here), or you can use info exists varName.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
replace TCP::close command with reject in code above to avoid core dumps
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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 ?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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).
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
9.4.8 HF3 failed as well using the iRule.

Does anyone have suggestions?
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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.
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
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
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER
Thanks for the quick follow-up hoolio.
0