3
$\begingroup$

I'm getting mixed reports on this one. I have a web host and multiple SSL scanning tools (including the one run by Qualsys SSL Labs), saying that the cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is NOT vulnerable to Zombie POODLE/GOLDENDOODLE, and at the same time I have a PCI compliance firm indicating that it is vulnerable. Unfortunately still, neither are willing to budge on the matter or provide much more detail than what I've already mentioned here.

I don't know a whole lot about crypto, but I know enough that having "CBC" in the name of the cipher suite alone suggests that it implements cipher block chaining, and by extension means it has the potential of inadvertently revealing a padding oracle, and is thus vulnerable to Zombie POODLE attacks. If that's the case, then why are all of the SSL scanning tools I've used suggesting otherwise?

Also, I realize there are valid arguments against using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 in general, but that's outside the scope of this question, as I'm really only concerned with whether or not it is vulnerable to Zombie POODLE/GOLDENDOODLE attacks specifically.

$\endgroup$
2
  • 1
    $\begingroup$ They're both implementation problems so is it always vulnerable? No. But could it be vulnerable? Yes. By disabling the cipher suite it eliminates the possibility of there being an issue. $\endgroup$ Commented Mar 28, 2022 at 14:54
  • $\begingroup$ How can I prove that it isn't being implemented? Is this something the host can provide apart from saying just so? Is there a way for me to test this on my side? How does SSLLabs verify that it isn't being implemented? $\endgroup$
    – soupmagnet
    Commented Mar 28, 2022 at 15:30

2 Answers 2

4
$\begingroup$

The cipher suite indicates that PKCS#7 padded CBC is used with a MAC verification only performed after decryption. That means that it is vulnerable to plaintext oracles before MAC verification.

The unpadding is mainly at risk not because padding oracles are more likely to leak information compared to other plaintext oracles, but simply because unpadding would normally take place before the MAC is recovered.

The implementation trick is to not unpad explicitly as the length of the plaintext is known in advance, and to perform a (preferably time constant) compare of the HMAC created authentication tag before any of the plaintext bytes are used.

If the implementation is unknown then the PCI compliance firm is right, it does introduce a risk. It is one that can be relatively easily avoided by using TLS 1.3, or TLS 1.2 using GCM or CCM mode of operation for AES.

$\endgroup$
4
  • 1
    $\begingroup$ Not necessarily: the server could implement rfc7366 and refuse any client that doesn't allow/support it; that would eliminate the oracle. But for (traditional) plaintext-HMAC, I don't think the compare time matters, only the tag computation, for which you would have to alter the inner hash computation in the HMAC to not stop at the unpadded length. (Also data-HMAC doesn't use PRF, although 1.2 PRF and 1.3 HKDF use HMAC.) (And concur AEAD, which also includes ChaCha/Poly, is the easier fix.) $\endgroup$ Commented Mar 29, 2022 at 4:43
  • 2
    $\begingroup$ Also PCI is pure box-checking. They've likely got a box that says "no CBC", and whether the implementation is secure is irrelevant. It's legal compliance, not security. $\endgroup$ Commented Mar 30, 2022 at 14:04
  • $\begingroup$ @dave_thompson_085 I've excluded ChaCha as it isn't NIST approved as such, and therefore it is likely to hit another checkbox problem :) As for RFC 7366, I'm not sure how many implementations are complicit, so it depends on that if it is feasible. Thanks for adding all the depth though :) $\endgroup$
    – Maarten Bodewes
    Commented Mar 30, 2022 at 17:13
  • $\begingroup$ The gist of this answer is correct but there are a few inaccuracies. TLS doesn't use PKCS#7 padding, it's slightly different but has the same problems. The plaintext length is not known in advance, which makes it hard to implement the unpadding securely: the countermeasure (the only secure one AFAIK) is to compare the MAC at all possible positions, and combine the results very very carefully. PCI has nothing to do with NIST, so Chachapoly shouldn't be a problem (of course, here, the problem is the auditor, so who knows). $\endgroup$ Commented Mar 31, 2022 at 15:59
3
$\begingroup$

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 is a protocol (a subset of the TLS protocol family). Zombie POODLE and GOLDENDOODLE are vulnerabilities in some implementations of this protocol. So if the compliance firm is claiming, knowing only that your server accepts this cipher suite, that your server may be vulnerable to these attacks, they're correct. If the compliance firm is claiming that as soon as your server accepts this cipher suite, it's vulnerable to these attacks, then they're wrong.

These attacks are based on an analysis of error responses sent by a TLS server when it receives bad input (which may come from a malicious client or a man-in-the-middle. (This analysis includes the potential absence of a response as well as the timing of the response.) Both are padding oracle attacks. All TLS cipher suites that use CBC are vulnerable to padding oracle attacks if implemented naively. Pretty much every TLS implementation was vulnerable to Lucky Thirteen when it was disclosed in 2013, and some may still be vulnerable to variants of it, but OpenSSL and several other major TLS stacks now implement countermeasures which fully protect against padding oracle attacks if implemented correctly. Those countermeasures are intrinsically slow, and subtle, so you may not want to rely on them, but for the level of security expected for PCI compliance, they are sufficient.

If your server uses OpenSSL or the Windows TLS stack or most major TLS implementations, it's safe. (OpenSSL was vulnerable to another similar attack discovered at the same time though, dubbed “0-length OpenSSL” because it was very specific to OpenSSL's behavior.) What you mainly need to worry about is some middleboxes that decrypt TLS traffic (firewalls, load balancers, …). Even so, as long as you're applies all security patches, you should be fine (and if the latest firmware is still vulnerable, drop your vendor immediately).

In any case, you can use the scanner provided by the researchers who discovered the attacks to test your systems. This is the same scanner that Qualys (and undoubtedly others) use, so if Qualys says your system isn't vulnerable, you don't have a security problem: your only problem is to convince your auditor.

If your auditor is anywhere close to competent, they should either run this scanner or use a service that runs this scanner, and conclude that your system isn't vulnerable. But judging by their response, they may be less than competent. A good auditor would have known, and been able to explain, everything I've written here. It's also weird that the auditor only mentions those two attacks against CBC-based cipher suites and not older ones such as BEAST, Lucky Thirteen, etc.

How much do you care about supporting CBC cipher suites? While they can be implemented securely, that requires that all your servers and TLS-intercepting middleboxes are high quality, and it comes with a performance penalty. If you don't need them, I recommend disabling them. Generally, for TLS, a good balance between security and compatibility is to only use signature-based cipher suites (i.e. with ECDHE or possibly DHE in their name, in addition to RSA or ECDSA), with AEAD (CCM, GCM or CHACHA20_POLY1305). Some other cipher suites can be secure, but have increased risk of implementation vulnerabilities.

So my strategy with this auditor would be:

  1. Check if you actually want CBC cipher suites. If not, disable them and tell your auditor that this point is moot.
  2. If you do need CBC cipher suites, remind the auditor that these are implementation vulnerabilities and argue that Qualys says the implementation is vulnerable. If they're still not convinced, run the padding oracles scanner yourself and invite your auditor to do so as well.
  3. If the auditor really won't hear anything, you may be left with no choice but to change auditors. At this point we've strayed far away from cryptography and into the business realm.
$\endgroup$
3
  • $\begingroup$ BEAST isn't padding and is fully blocked by enforcing TLS>=1.1 which PCI already requires and thus presumably was checked by the scan. (It can also blocked by fragmenting, and at the time practically everybody did 1/n-1 while OpenSSL had already done 0/n, but for PCI that's moot. Also at the time many promoted RC4 to avoid CBC, but that turned out badly.) $\endgroup$ Commented Apr 1, 2022 at 0:22
  • $\begingroup$ Very thorough explanation. Thank you. The real problem for me was, if neither party was willing to give in, then which one to get rid of? From my perspective the decision should be based on overall competence in such matters to avoid getting caught in the same exact situation with the next provider. $\endgroup$
    – soupmagnet
    Commented Apr 2, 2022 at 21:10
  • $\begingroup$ @soupmagnet Ultimately, your auditor decides whether you're certified. That's not a matter of being right, it's a matter of getting them to pass you. $\endgroup$ Commented Apr 3, 2022 at 20:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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