On 12/21/2011 12:18 AM, Hasan, Rezaul (NSN - US/Arlington Heights) wrote:
Hello All,
You will have a much better chance of getting an answer if you don't use the "Reply" button to start a new discussion. Most readers of this list/forum use software which groups together replies under the message you replied to, so the following questions of yours ended up deep inside a discussion on subtle issues in the handling of names in certificates.
We have openssl 0.9.8r on our Linux Server.
Are you sure it is really a real version "0.9.8r"? it could also be "0.9.8r" + later security fixes backported to work with version "0.9.8r" by your Linux vendor.
A Nessus security scan on our Linux server tells us that we may be vulnerable to a potential DOS due to SSL/TLS Renegotiation Vulnerability [CVE-2011-1473].
Renegotiation vulnerabilities are notorious for being impossible to detect reliably from the outside, this may or may not be a false alarm.
The suggestions of mitigating these (we believe) are:1. Disable Re-Negotiation completely. {We CANNOT use this choice, because our system does need to allow Re-Negotiation in some cases. So NOT an option for us}
What server software is this? Is it Apache httpd? Some other software?
2. "Rate-Limit" Re-Negotiations. Can someone please provide detailed information/guidance about exactly how to go about "Rate-Limiting" Re-Negotiation requests on the Linux Server? Pointing to a detailed article would also be helpful.
In general, Rate limiting is done by having a function in your software called whenever something happens (such as Renegotiation) and inside that function, keep a count of how many times it was called in each of the past X minutes. If the total is over the relevant limit for this vulnerability, then either delay the operation by enough time to stay under the limit or artificially fail the operation in such a way that the remote client (which may be an enemy) cannot tell anything about what happened in that renegotiation, such as if it would have succeeded if there was no rate limit. Unfortunately, I do not know the specifics of this vulnerability or how low the "safe" rate would be. 3. There is a 3rd option: Actually install or create a proper fix for the vulnerability, thus eliminating the need for workarounds. Hopefully, others on this list knows more about this issue and can tell you what is needed to be safe. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
