Please advise me how to find SSL Renegotiation Manually?
Also, Advise me any tools available and what the output expected out of it ?
I had a THC SSL tool but unable to understand what is the valid response expected
However, the procedure will only work if you are testing from a server that uses an old version of OpenSSL (version 0.9.8k downloaded directly from the OpenSSL web site).
Thanks Ivan! Can you tell me, Upto which versions of SSL can be tested with the above process (you mentioned)?
Do you mean - It can be tested till version 0.9.8k ???
The connection blocks and timeouts after a while, which is how OpenSSL 0.9.8l deals with renegotiation - Does it mean it is not supporting SSL Renegotiation in Version 0.9.8I?
Raghu Nallani Chakravartula
You can test any version of OpenSSL or any other SSL implementation, provided you stick with 0.9.8k on the workstation from which you are initiating the tests.
As for 0.9.8l, that version of OpenSSL does not support renegotiation of any sort as far as I know.
Quick question on how openssl 0.9.8k can detect secure renegotiation. Its ouput includes “Secure renegotiation IS [or IS NOT] supported” – but how can that version of openssl know about secure renegotiation because the 0.9.8k version (Mar 2009) pre-dates the vulnerability by several months – there was no concept of secure vs insecure renegotiation until Nov 2009 when the flaw was exposed. I can see from Wireshark that openssl 0.9.8k uses the cipher spec TLS_EMPTY_RENEGOTIATION_INFO_SCSV in its Client Hello (instead of the TLS exention) but this wasn't defined until the problem of insecure renegotiation was solved. It's almost as if 0.9.8k had advanced knowledge of the flaw?!
Thanks for any clarification.
As you say, the older versions of OpenSSL cannot detect secure renegotiation. They can only detect insecure client-initiated renegotiation. With a newer version of OpenSSL you can do two things: 1) Detect if a server understands secure renegotiation and 2) determine if it allows client-initiated renegotiation.
As for your 0.9.8k using TLS_EMPTY_RENEGOTIATION_INFO_SCSV, that does sound very unusual. Is it a vanilla version downloaded directly from openssl.org, or the version provided by the operating system? If it is the latter, it may be that they are distributing a patched version under the same version string.
Thanks Ivan. I thought it might have been patched too as it was on BackTrack, and running strings on the binary and grepping for "Secure Renegotiation" produces a hit but you don't get a hit against the openssl-0.9.8k source code from openssl.org. Reading your response I went a step further and compiled the original source. I ran it and looked for what it was sending using Wireshark: no TLS_EMPTY_RENEGOTIATION_INFO_SCSV and the output is missing "Secure Renegotiation IS supported". So it must be a patched version. Case closed!
Hi. I wonder if you could comment on my reading of a couple of renegotiation issues. If I understand it correctly...
1. A server can support both insecure and secure renegotiation at the same time, in that the CVE-2009-3555 patch has been applied but the server is able to "fallback" to insecure renegotiation if the option exists and has been set. This is what the SSLInsecureRenegotiation directive does in apache mod_ssl.
2. Tools such as sslyze depend on the version of openssl installed. Running on the latest openssl the tool can happily check for secure renegotation but, assuming point (1) above is correct, it's possible that the server could also support insecure renegotiation, which the tool can't check because the openssl libraries won't allow it. Therefore the output of such tools (as always) has got to be interpreted carefully, i.e. it it may declare secure reneg is supported but it may miss that insecure reneg is also supported.
Also, any pointers on installing two versions of openssl side by side, i.e. the latest along with 0.9.8k? Install to a different directory and chroot a program perhaps? Maybe it's just easier to use a VM!
1. Yes, it is possible that a server supports both insecure and secure renegotiation. I've seen it a number of times, too. Looking at the documentation (I haven't tried it myself), Apache's SSLInsecureRenegotiation can be used to achieve this.
2. I am not familiar with the internals of sslyze, but most SSL testing tools are tied to a particular version of OpenSSL or some other underlying library. (SSL Labs is not.) Specifically about renegotiation, it will depend on exactly how the tests were implemented. It might be possible to build a reliable test for renegotiation with a newer version of OpenSSL.
I share your view that interpreting results is tricky, unless you are very confident about the tool. To this day I keep around several versions of OpenSSL for manual testing, as well as use Wireshark regularly to determine what exactly is going on.
As for running multiple versions of OpenSSL -- that's easy: simply compile like this:
$ ./config --prefix=/opt/openssl --openssldir=/opt/openssl
No need to install becuse the resulting openssl binary should be statically compiled.
Quick question for me too: When I was testing the renegotiation capabilities of my server, the result I had was "Renegotiation not supported". It got me confused since I'm using SSL on my server. Any chance, the test result meant "Secure Renegotiation not supported"?
It shouldn't be confusing: renegotiation is not a required feature and can be disabled.
Retrieving data ...