BEAST should only apply to HTTPS

[polarathene]

Did you check the documentation in ~/doc/ or, if it is a different problem: Did you google for it?

Yes (page 5):

What is not affected

• HTTPS using TLS 1.1 or higher
• Protocols other than HTTPS
  • Imap
  • POP
  • SMTP
  • FTPS
  • SSH
• Post Data
• HTTPS using compression (not found very often)

What exactly was happening, output is needed

When SSL3 or TLS1 is available on a port that skips HTTP protocol checks, BEAST is checked and flags as vulnerable if a CBC cipher is detected.

What did you expect instead?

When HTTP checks are skipped, BEAST should also be skipped as it doesn't apply.

[keisentraut]

The BEAST attack was demonstrated in 2011 for HTTPS only, but the actual issue is the combination of CBC and SSLv3/TLSv1.0. It still is cryptographic weaker to use CBC with SSLv3/TLSv1.0 than CBC with TLSv1.1+. For more details, please read BEAST-PoC, especially the following quote from there:
This is also an implementation of the vulnerability originally discovered by Phillip Rogaway. Discovered in 2002, there was no exploit released until BEAST in 2011. OpenSSL already knew the problem and this why they updated TLS1.0 to TLS1.1 in April 2006.

If you use a custom protocol other than HTTP, someone could come up with some new clever way to exploit CBC with TLSv1.0 and your custom protocol. It is not very likely in practice, but we do not know all custom network protocols out there. My recommendation (as a simple testssl.sh user like you) is to leave the BEAST check of testssl.sh (function run_beast()) as it is: It does not consider the type of service at all. It simply checks if you offer SSLv3/TLSv1.0 with CBC ciphers or not.

Nowadays, CBC ciphers and TLS version smaller than 1.2 are frowned upon anyway. So one can argue to completely remove the BEAST test completely, because vulnerable servers will always have at least two other findings (support of SSL3/TLSv1.0 and support for obsolete CBC ciphers) anyway.

[polarathene]

TLS version smaller than 1.2 are frowned upon anyway.

When it comes to modern clients interacting with servers for web, sure.

Otherwise it can get a bit complicated and sometimes there is additional lag. Eg with mail servers, you can argue port 25 needs to support cleartext delivery regardless, but while TLS 1.2 was standardized in 2008, it wasn't until around 2010-2012 that it was more widely available to deploy, while some other common server OS releases didn't support it properly until 2014-ish (ECC or cipher suites such as those with GCM were not always supported by certain TLS 1.2 client/servers).

You also have hardware/firmware products which never receive updates for such, such as scanners/printers or old media systems. Even in 2020, there are some users on Android 4.x which often lacks TLS 1.2 support. Until around late 2016 macOS/iOS lacked support for TLS 1.2 on non-HTTPS protocols such as IMAPS for mail retrieval, and users can still be found stuck on those earlier OS releases on their devices in 2020.

In larger organizations like hospitals and schools, sometimes it's due to networking hardware lacking support for TLS 1.2 and acting as a firewall/proxy to the public internet, so regardless of devices on those networks having better support, or the servers being connected to, this can lag adoption there, and then there's software which can for a variety of reasons can also lack TLS 1.2 support and not easily receive it, both in consumer apps and enterprise / legacy software.

Finally, regarding dropping CBC cipher suites, yes you'd generally want AEAD ciphers instead such as GCM or ChaCha20, both which need TLS 1.2. GCM is notably slower in software vs ChaCha20, and even in 2020, there are still new devices being shipped which lack hardware accel for AES(+GCM), while ChaCha20 support is still limited in clients and would only be found on clients/servers from 2016 onwards. Embedded devices may prefer AES-CCM for such (also AEAD and available in TLS 1.3, although OpenSSL disables it by default).

In most cases, if you can require TLS 1.2 as minimum, you probably don't need CBC cipher suites, they're fine to use atm afaik (and there is a TLS extension to negotiate using Encrypt-then-MAC instead), but if you don't need them and can just stick to offering AEAD ciphers, that's the better route to go.

[drwetter]

haven't found the time yet to look into it.

[keisentraut]

Otherwise it can get a bit complicated and sometimes there is additional lag. [...snip...]

I agree with all of this, but compatibility issues do not matter for a vulnerability scanner. If you want to use SSLv3, then fine, but you need to accept findings in vulnerabilty scanners, too.

My point is:

1. BEAST is a weakness in the TLSv1.0 protocol (reusing cipher text as IV for CBC ciphers) itself. We do not know all custom protocols in the world which are using TLS. A BEAST-alike attack might apply to one of those services. You are right, we could disable the BEAST check only for well-known protocols known to be non-vulnerable such as SMTPS, LDAPS, ... But then, are you 100% sure e.g. LDAPS is not vulnerable? You won't find any papers claiming e.g. LDAPS with TLSv1 and CBC is cryptographically secure. (Very stupid example: I take the Apache webserver and the Firefox browser and replace the 1.1 in the GET / HTTP/1.1 with 4.0. Now, my service is not HTTPS anymore, but still vulnerable to BEAST if I have TLS1.0 and CBC.)

2. Servers vulnerable to BEAST (medium-rated, if TLS 1.1+ available then low-rated) will always have at least two other findings with testssl.sh. If you fix one of those, you will not be vulnerable to BEAST. Therefore, the additional "BEAST"-finding of testssl.sh will not provide any new information:

• TLSv1.0 (low severity in testssl.sh)
• Obsolete CBC ciphers (AES, ARIA etc.) (low severity in testssl.sh).

We can discuss removing BEAST for all non-custom and non-HTTPS services, but then, why not remove it at all nowadays? Fun fact: The BEAST attack is so old that the recommendation back then was disabling all CBC ciphers and using the stream cipher RC4 instead... Obviously, this did not age well.

PS: My opinion does not matter, let drwetter decide :)

[polarathene]

2. If you fix one of those, you will not be vulnerable to BEAST

IIRC, you don't have much cipher choices that you can use below TLS 1.2 these days, I think it's only AES-CBC now? (at least with OpenSSL) So removing that would remove support for the lower protocol version which you are probably offering for third-party clients, such as with mail servers.

Generally these third-party servers would be older than 2014, some CentOS/RHEL releases around 2011 later received updates in 2012 for TLS 1.2 support (ECC support was stripped out until RHEL 6.5 however, and still missing from other packages like Java until RHEL 6.8). Java 8 (2014) is when TLS 1.2 support was available (Java 7 received support in an udpate but behind a paywall), and regarding mail at least, as mentioned macOS/iOS didn't support TLS 1.2 for such until near end of 2017, and some users still run those OS versions in 2020 for whatever reasons.

Thus your suggested fixes aren't viable if such clients still need to be supported, TLS 1.1 support usually is paired to when TLS 1.2 arrived in different software releases/updates. For mail though you aren't going to have a connection open where you're leveraging JS(or whatever) to manipulate the encrypted traffic/packets, so BEAST isn't going to be an issue there is it?

---

The attack is described as:

If the attacker knows what kind of data is being sent and where it is in the message

XOR is reversible, so the attacker can mount a chosen plaintext attack by guessing a likely block of data and XOR-ing it with the IV and the preceding block of ciphertext, and injecting the result into the session.

the attacker is brute-forcing one byte at a time, so guessing a 10-digit number would require just 10 guesses for each digit and no more than 100 attempts for the whole number (50 on average).

The approach described by Duong and Rizzo relies on the rigid structure and predictable content of HTTP packets, especially containing equally predictable HTML code.

By carefully crafting HTTP requests, it is possible to control the location of cipher block boundaries (hence the name Blockwise Chosen Boundary Attack) and create a message where all bytes are known except the targeted data – typically the session cookie.

The attack was limited to recovering short strings and required a relatively large number of requests but even so, in specific situations, it could be used to read session cookies or login credentials.

Without closing this site, the user then logs into a high-value website, such as an online banking application, and keeps both sites open for 10 minutes or so. The attack script runs in the background, attempting to brute-force the active session cookie. If the attack succeeds, the attacker can hijack the banking session and impersonate the user until the legitimate user logs out.

Thus you need a protocol with predictable packet structure containing known plaintext, and be able to manipulate that data within a session to pull the attack off. Such manipulation isn't practical if you're unable to setup a separate communication channel to the server under that same TLS session, and requires you to manipulate from the client side prior to encryption? (not just MitM manipulating/inspecting already encrypted packets)

I don't know the protocols on a technical level well enough, but if they were vulnerable they'd be much more information online by now about this type of attack being applied to them. HTTP works differently with request/response, the linked document I provided makes it clear that quite a few protocols are deemed safe from such an attack.

---

But then, are you 100% sure e.g. LDAPS is not vulnerable? You won't find any papers claiming e.g. LDAPS with TLSv1 and CBC is cryptographically secure.

I trust OWASP well enough when they publish such information stating specific protocols are safe from such an attack. Trusting CBC in general for TLS (as is older versions) is a different story.

We can discuss removing BEAST for all non-custom and non-HTTPS services, but then, why not remove it at all nowadays?

Browsers should be updated and patched afaik to prevent it already, but you may still want to be made aware of it if you do expose TLS 1.0 or earlier for HTTPS perhaps on an intranet with systems that are rather out of date. For most it may not be relevant anymore, but testssl.sh at least raises awareness about it and might encourage the reviewer to look into it further and educate themselves about how such attacks work. Useful if they feel they must continue to support the old protocol versions and potentially are vulnerable.