TLS Renegotiation Test
November 28th, 2009 by Nasko
The new TLS/SSL man-in-the-middle (MiTM) attack targets the renegotiation part of the protocol. There are two variations of the renegotiation – client initiated and server initiated. This tool allows you to test any web server (input as server:port) for client initiated renegotiation support, as server initiated renegotiation depends on specific server configuration. As currently there is no fix other than disabling renegotiation, this will pretty much tell you whether the server is vulnerable or not to this type of renegotiation attack
Tags: man-in-the-middle, MiTM, renegotiation, SSL, TLS, TLS1.1, TLS1.2, vulnerability
November 30th, 2009 at 08:07
[...] This post was mentioned on Twitter by PhoneFactor, Marsh Ray. Marsh Ray said: RT @naskooskov TLS client initiated renegotiation test http://netsekure.org/2009/11/tls-renegotiation-test/ [...]
November 30th, 2009 at 13:21
[...] has set up a nice test for client-initiated renegotiation on his blog. This is probably the most pervasive, and simplest to exploit, form of the SSL/TLS [...]
December 13th, 2009 at 04:27
[...] Test Here: TLS Renegotiation Test | netsekure rng [...]
April 24th, 2010 at 12:59
Hey Nasko,
This is pretty cool. We are a bunch of grad students who are trying to simulate the TLS renegotiation vulnerability in virtual testbed environment. I just stumbled on to your link today, 2 days before the final presentation of our project.
Can you please share the source code of this Renegotiation Test with us ? We hope that we will get back to you with a better implementation useful for our project as well as for putting up on your website.
Let me know if you have any questions.
Thanks and regards,
Nipun
April 24th, 2010 at 13:01
We are trying to make the use of X-ignore in HTTP header to simulate the attack. And, it seems like you use telnet to get the output here. Are you only testing for Client-initiated renegotiation ?
April 26th, 2010 at 08:17
Yes, I am only testing client initiated renegotiation. It says so on the page itself : ). Server initiated renegotiation depends on a bunch of factors, so it is hard to produce a generic test.
April 26th, 2010 at 08:18
I’ve emailed you with details, so let’s keep in touch and see how I can help you with your project.
June 21st, 2011 at 08:45
Hi Nasko,
I try to build a nagios plugins for this check.
Would it be too much if i ask you to send me your source code whatever language you used.
Thanks in advance,
Orel
June 21st, 2011 at 13:10
Sure, I’ll contact you over email.
June 22nd, 2011 at 02:34
Hi. What about patched servers that use secure renegotiation? Twitter.com is an example. I think such sites are fine. Although you report the “site supports secure renegotiation”, you also include the warning “unpatched servers … are vulnerable”. When not reading carefully, one might get the impression that the patched server is still vulnerable. I understand your test is from 2009, when disabling renegotiation was the only remedy. However, if you continue to operate this test, maybe you want to consider to remove this warning for patched servers? Regards, Kai
June 22nd, 2011 at 06:02
Hi Kai,
The tests has two pieces to it – check if client initiated renegotiation is supported, which was the initial easiest attack vector and check if secure renegotiation is supported. While a server supporting secure renegotiation is great, if the client connecting to it is not patched, the connection is still vulnerable. As such, I kept both pieces of information in the test, such that you can get the full picture out. I could update the actual post, but hopefully this comment will clear things up.
Nasko
June 22nd, 2011 at 12:15
Nasko, I don’t have your email. If you want, please cancel this message, and let’s discuss by email first.
Thanks for explaning your intention. I also tested using an old client to a patched server, and I get different results than you you report.
If I use an old client, connect to twitter.com:443, send one byte of data, then request a renegotiation, then wait for something to happen… nothing happens. The server ignores my request for a handshake. I think this means the server is fine.
How does your test work? Do you send your request after the second handshake?
August 11th, 2011 at 13:46
[...] TLS renegotiation attack is explained at educatedguesswork.org, and tested at netsekure.org. Note that there are many mitigation methods (alunj blog, F5 community post), so simply having a [...]