I've seen a lot of articles giving the official explanation on how to prevent OpenSSL Padding Oracles, Usually all of them state that its CBC cipher suites that leave you vulnerable.

The following list works for me, and gets me an A on SSLLabs.

SSLProtocol -all +TLSv1.2
SSLHonorCipherOrder On

My problem is that I cannot add any more without getting an F, and being open to the Padding Oracle in question.

If I then compare this to the results of a security heavy website like http://binance.com. They get A+ AND they have CBC ciphers present.

My question then, how can I protect against OpenSSL Padding Oracle (CVE-2016-2107), whilst enabling more ciphers? Is there more configuration I can do elsewhere to protect, whilst allowing a larger range of ciphers (WEAK or not)? I also see that TLSv1.0 and TLSv1.1 can also be enabled with a limited range of ciphers too.****

My reasoning here is that my current list is preventing Safari 6-8, Android 2-4, and Windows 7 IE 8-10 users. I'd like to open this up.


1 Answer 1


Please have a look at the specific CVE where it is clearly documented what is affected by the issue in the first place:

The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC

From studying the linked resources you'll find out that the fix is not to disable specific ciphers but to make sure that you don't run any of these affected versions. From the relevant OpenSSL advisory:

OpenSSL 1.0.2 users should upgrade to 1.0.2h
OpenSSL 1.0.1 users should upgrade to 1.0.1t

  • I'm no security expert so honestly it's not super clear. I'm just reading articles that are telling me to change my Cipher Suite! Anyway, the openssl version command yields: OpenSSL 1.1.1a 20 Nov 2018. I see no mention of this, so how am I still open to Padding Oracle attacks? Feb 28, 2019 at 18:39
  • @confused_unicorn: Why exactly do you think you are vulnerable, i.e. can you link to the relevant report from SSLLabs? And are you sure that your Apache is actually linked against the openssl version you report? This is likely not the case if you've just installed it manually and did not explicitly build Apache against this version. Feb 28, 2019 at 19:02
  • So I can't link the report because as I don't want to publicly announce any security vulnerabilities in our app. However SSLLabs reports F if I put back my ciphers, and specifically tells me I am vuln. to OpenSSL Padding Oracle. It simulates handshakes with OpenSSL-1.0.1l and OpenSSL-1.0.2e over TLSv1.2 Feb 28, 2019 at 19:19
  • Thanks you Steffan. I was vulnerable, and I upgraded OpenSSL to 1.0.1t, (even though the version was saying 1.1.1a, it was still apparently vulnerable). Putting it at 1.0.1t and re-enabling TLSv1.0 and TLSv1.1 with all GCM and CBC ciphers, I still get an A and am protected from Padding Oracle Feb 28, 2019 at 19:55
  • @confused_unicorn: the version reported by openssl version and the one which is actually linked to Apache can be different. In fact, you can have multiple versions of openssl binary and openssl version on the system but Apache is only linked against one version which might not be the latest one. Feb 28, 2019 at 20:26

You must log in to answer this question.

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