TLS Renegotiation Test

13 Comments

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: , , , , , , ,

13 Responses to “TLS Renegotiation Test”

  1. Tweets that mention TLS Renegotiation Test | netsekure rng -- Topsy.com Says:

    [...] 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/ [...]

  2. Extended Subset » Blog Archive » Assorted news Says:

    [...] 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 [...]

  3. MitM Plaintext Injection Vulnerability in TLS (openssl) « waffle Says:

    [...] Test Here: TLS Renegotiation Test | netsekure rng [...]

  4. Nipun Says:

    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

  5. Nipun Says:

    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 ?

  6. Nasko Says:

    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.

  7. Nasko Says:

    I’ve emailed you with details, so let’s keep in touch and see how I can help you with your project.

  8. orel Says:

    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

  9. Nasko Says:

    Sure, I’ll contact you over email.

  10. Kai Engert Says:

    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

  11. Nasko Says:

    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

  12. Kai Engert Says:

    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?

  13. Attacks « Aggressive Virus Defense Says:

    [...] 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 [...]

Leave a Reply

You must be logged in to post a comment.