Our vulnerability scanner (Saint-based) is claiming that a large number of devices and servers are susceptible to the SSL/TLS renegotiation flaw (CVE-2009-3555). Most of these servers and devices are fairly up-to-date on patches / firmware.

Since the issue is 5+ years old, I suspect that the issues reported are mainly false positives.

To verify, I ran this:

openssl s_client -connect x.x.x.x:443
GET / HTTP/1.1
depth=0 CN = X.X.X.X, L = Utopia, ST = UU, C = US, O = Acme, OU = IT
verify error:num=18:self signed certificate
verify return:1
depth=0 CN = X.X.X.X, L = Utopia, ST = UU, C = US, O = Acme, OU = IT
verify return:1


So the server is saying, "RENEGOTIATING", which seems to indicate that it is vulnerable but it does not deliver content upon the subsequent CRLF, which seems to indicate that it is not vulnerable.

Based on the above, is this device vulnerable? Is there a better way to test? I just need a reliable way to confirm before writing off as false positive or trying to find a fix.


Jim, based on your results, the host is vulnerable. You should have received a ssl handshake failure if your host was patched. You should open a case with your vendor and as for a work-around or a patch.

140735200371552:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:615:

That is what you should have seen.

  • yes, but from what I have read there is more to it than that for the server / device to actually be vulnerable. The SSL implementation could allow for the attack, but that does not necessarily mean that the end-point is vulnerable. See g-sec.lu/practicaltls.pdf (p. 24, "Vulnerability Requirements"): "The server treats both sessions as one and merges them at the application layer" The fact that the server is not delivering any data seems to indicate that it is not vulnerable. Do you agree? – Jim Balo Jan 5 '15 at 21:09
  • I would be speculating at this point. I would get the official answer from your vendor and document it internally so that you are covered. – Aaron Jan 5 '15 at 21:21
  • I dug deeper into one of the supposed vulnerabilities (vCenter), and despite responding to the openssl test above, it is not vulnerable: kb.vmware.com/selfservice/microsites/… The more I dig into this, the more I am becoming convinced that my test above indicates that the device / server is NOT vulnerable, since the end point is not allowing the two sessions to be merged. – Jim Balo Jan 5 '15 at 21:22
  • There are two kinds of renegotiation: the original insecure one, and the fixed rfc5746 one; if 5746 is implemented, which s_client tells you in the snipped part, R->RENEGOTIATING is safe. @Jim: if the stack allows non-5746 renegotiation, the server is vulnerable if it receives data and uses the security parameters of the handshake particularly client-certificate; what the server sends doesn't matter in itself. – dave_thompson_085 Jan 28 '15 at 10:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.