5

I recently ran my website through the Qualsys SSL Labs SSL Test. My website got a grade "F" with this message attached:

This server is vulnerable to the OpenSSL Padding Oracle vulnerability (CVE-2016-2107) and insecure. Grade set to F.

Being bothered by this, I contacted my web host about my concerns, and the response they gave me was:

The scoring is false, since the distro we using, it uses Open SSL, but it is patched while retaining the original numbering version. it is already patched but Redhat do not change the OpenSSL version to latest version due to how they build their packages.

This sounded fishy to me, since I didn't think it made sense for such a test to check what version of OpenSSL is running (how do you even check for that from the "outside"?), but rather to test that the vulnerability is present by trying to execute an attack against it. So I complained some more, including letting them know that other vulnerability testers mark it as vulnerable. Their response to that was:

It is already patched. Just they report it as bad due to the version number reported when checking it. Lot of checkers fails it due to that specfic reason itself.

Should I trust the response from my web host, or should I run as far away as I can as quickly as I can? If they are telling the truth, are there vulnerability testers that are not fooled by incorrect OpenSSL version numbers?

Improve this question
1
  • If you are able to use the Nikto tool, it checks for the presence of this vulnerability.
    – iainpb
    Commented Mar 12, 2017 at 10:19

1 Answer 1

Reset to default
2

The version would most likely be checked based on HTTP header or default error pages. This also seems to be the assumption of your hoster, which says that they are sending out the wrong version, which results in false-positives.

Qualys however says that they do not test this via version, but via a test that is based on this test.

Cloudflare describes the test (and also the vulnerability itself):

Detecting a vulnerable server is as easy as sending an encrypted message which decrypts to AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, and checking if the TLS alert is DATA_LENGTH_TOO_LONG (vulnerable) or BAD_RECORD_MAC (not vulnerable)

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .