0

Title summarizes my question best.

I am trying to make my ubuntu 10.0.4 server PCI compliant, and to do so, the last bullet on the list is to make sure it isn't vulnerable to the BEAST attack. To do this, I can disable SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS, but according to the following link:

http://people.canonical.com/~ubuntu-security/cve/2011/CVE-2011-3389.html

this will break compatibility with certain implementations of SSL, without really offering much of a security benefit since the BEAST attack is impractical and modern browsers don't allow arbitrary code to run.

The end goal is the following: be PCI compliant, but without an impractical solution (e.g. I'm not willing to disable TLS 1.0).

Edit: moved secondary question to a separate question: Where can I find the file to set SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS

Community
  • 1
jperezov
  • 133
  • 1
  • 7

1 Answers1

3

If your goal is to be PCI compliant without creating a mess for yourself screw the BEAST attack.

Seriously, every modern browser has worked around BEAST for years now. Either declare it a non-problem in your policy documentation, or if your auditors are idiots take the position that if someone is using a browser that is susceptible to BEAST you will simply deny them access to your site and instruct them to upgrade their lousy, out-of-date, insecure browser (and have your applications team implement that via browser detection).

The next best mitigation aside from "screw the BEAST" is to disable TLS/1.0 - and require that all clients use TLS/1.1 or higher. (This is really a variant of "Screw the BEAST", enforced by outright refusing to talk to any browser crappy enough to be vulnerable).
Breaking compatibility for people with lousy security is the only way you'll get them to upgrade.

If you still don't want to do that you can mitigate the problem by disabling ciphers that are susceptible to BEAST, but doing so has other (nasty) security implications that PCI in its infinite shortsightedness doesn't care about.
You will be closing a "security hole" (air quotes, because it's pretty well worked-around) to open a security hole (a potential vector for malicious attackers to compromise your site in the real world, without the nice compensating controls that BEAST has).

Community
  • 1
voretaq7
  • 79,879
  • 17
  • 130
  • 214
  • While I would love to do this, the third-party scanner my company is using for PCI compliance is being rather stubborn about the whole BEAST issue. I am well aware that the BEAST attack isn't that much of an issue anymore, and that most "fixes" break something else. My question is "which fix breaks the least", under the assumption that SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS might be such a fix. Disabling TLS/1.0 would block out too many of our customers for us to go that route, hence why I specified that I was unwilling to do that. – jperezov Feb 18 '14 at 12:24
  • @user3191820 "Find a competent auditor" is the best advice I can offer you. My answer above addresses the rest of your questions: Every fix will break *something* (inserting empty fragments shouldn't break *anything that matters* but your system may still show up as vulnerable on scans). – voretaq7 Feb 18 '14 at 15:58