mitigating the TLS client-initiated renegotiation MITM attack

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.