Initial test for SSL renegotiation added to SSL Labs
I've added an initial implementation of the test that determines if an SSL server is vulnerable to the Authentication Gap MITM attack. At this point the assumption is that no server supports the safe renegotiation TLS extension, which means that a warning is displayed if renegotiation is found to be supported.
In the following days, as the implementations of the safe renegotiation TLS extension start to arrive, I will improve the test to take that into account.
Very good initiative. Thanks.
The implementation and presentation is very slick. Are you considering lowering the score for vulnerable systems?
Posted by: Christian Folini | November 23, 2009 at 09:42 AM
Perhaps I have not Googled enough but I am having a hard time finding out what non-experts like me should do at this point. I assumed that rebuilding Apache/1.3.41 Ben-SSL/1.60 with OpenSSL 0.9.8l would be the fix. According to your test page (thank you!), it isn't. Now what?
Posted by: Jay Rouman | November 23, 2009 at 04:48 PM
Jay, I would expect the updated OpenSSL version to deal with the problem. Please send me the address of your SSL server and I will manually test. Perhaps my test is wrong!
Posted by: Ivan Ristic | November 25, 2009 at 07:46 PM
Christian, I am not sure. The score of most of the Internet would turn to 0 and, in many cases, vendors haven't released updated packages. Perhaps I can implement something along the lines of "your score would be XX, but it is zero because you haven't patched a critical vulnerability". Does that make sense?
Posted by: Ivan Ristic | November 25, 2009 at 07:49 PM
Ivan, you can test dex.edzone.net. I was getting tripped up using s_client and finding that every machine I hit reacted the same to the "R" command. So I was beginning to think they were all broken. Then I realized that you have to use an older version of openssl that doesn't have renegotiation disabled. Then (aha!) I could see that machines that supported renegotiation did in fact spit out data when renegotiation succeeded. Still, your test showed dex as vulnerable to the mitm attack but it did not respond to a renegotiation request. Of course I could have something else wrong.
Posted by: Jay Rouman | November 25, 2009 at 11:16 PM
Jay, judging from a manual test I would say your servers are not vulnerable. But they don't refuse renegotiation -- the connection just hangs instead. I will see if I can fix my test tomorrow morning. Many thanks for your report!
Posted by: Ivan Ristic | November 25, 2009 at 11:33 PM
Jay, I don't know if you changed anything on your end, but when I tested dex.edzone.net a few minutes ago renegotiation came back as not supported https://www.ssllabs.com/ssldb/analyze.html?d=dex.edzone.net Could it be that you originally tested your servers before upgrading OpenSSL, and that SSL Labs continued to cache the results for 24 hours, causing you to think the renegotiation test was faulty?
Posted by: Ivan Ristic | November 26, 2009 at 12:07 PM
I don't think so because I didn't even discover your page until after I had upgraded openssl. I also rebuilt the web server so it obviously got restarted. I didn't capture the results page but I remember a line saying the server was vulnerable to a mitm attack. The server uses a self-signed certificate so I expected complaints about that. Results now are what I would expect. I can't account for what I saw earlier.
I guess it would be cleaner if the renegotiation didn't hang. This is Apache/1.3.41 Ben-SSL/1.60 and OpenSSL 0.9.8l running on Slackware. It's pretty vanilla...absolutely nothing special.
Posted by: Jay Rouman | November 26, 2009 at 07:37 PM