TLS_FALLBACK_SCSV: VULNERABLE - Signaling cipher suite not supported even though SSL and TLS 1.0 are not supported?

[Theory5]

Hello,

We are recommending this tool to be used internally by our developer and engineering teams for a quick check to see if they are or are not secure and using the proper cipher suites as they build new servers. THis is so the builder of the system can check to ensure they are mostly configured properly before requesting an audit from my group, which utilizes 'heavier' tools like Nessus. This is to attempt to reduce exposure scan times to a more manageable level.

Some users have been utterly confused at the presence (or lack of which) of the Fallback mechanism within the servers they are scanning.

These servers, as shown below, ONLY use TLS 1.1 and 1.2, and reject all lower connection attempts. HOWEVER, the Fallback plugin outputs this each time:

• SSLV3 Cipher Suites:
  Server rejected all cipher suites.
• Downgrade Attacks:
  TLS_FALLBACK_SCSV: VULNERABLE - Signaling cipher suite not supported
• SSLV2 Cipher Suites:
  Server rejected all cipher suites.

As you can see, the SSLV3 and SSLV2 protocols are not enabled. TLS 1.0 isn't either, but I can't show you the full output right now.

Why is the TLS_FALLBACK_SCSV reported as vulnerable? This is confusing our engineers a bit.

VULNERABLE - Signaling cipher suite not supported

Please correct me if I am wrong, but the TLS fallback configuration is only when you're running SSL v2/v3 and/or TLS 1.0, as those are vulnerable to many attacks and if an attacker downgrades the connection, they basically circumvent TLS 1.1 and TLS 1.2 protections. Right?

So why does this, when --regular scans are run, still report the fallback mechanism as being vulnerable? Does the fallback plugin not actually check to see if SSL or TLS 1.0 is enabled and simply reports on the condition of the signaling cipher suite? If this is true, it's not actually vulnerable, it's just that there isn't an SSL/TLS 1.0 check?

Can someone clarify? I'd appreciate some help so this tool can assist us in lowering the amount of time we spend on exposure requests. Thanks for your help!

[rdegraaf]

Hello,

TLS_FALLBACK_SCSV applies to all TLS/SSL versions, not just SSLv2 and SSLv3. By not supporting TLS_FALLBACK_SCSV, your clients may be vulnerable to downgrade attacks from TLSv1.2 to TLSv1.1, which removes their ability to use AEAD ciphers and SHA-2 hash functions. Just because TLSv1.1 is not currently known to be broken (in a practical, rather than theoretic, sense) is not a reason to allow downgrades.

From the RFC:

  If TLS_FALLBACK_SCSV appears in ClientHello.cipher_suites and the
  highest protocol version supported by the server is higher than
  the version indicated in ClientHello.client_version, the server
  MUST respond with a fatal inappropriate_fallback alert

See https://tools.ietf.org/html/rfc7507#section-3 for more details.

[Theory5]

Ah, gotcha, thanks! Given the whole situation with SSL and TLS 1.0, Allowing a downgrade from TLS 1.2 to 1.1 isn't that big of a vulnerability for our server configurations at this point in time. Not everything can run on TLS 1.2, or even 1.1, so exceptions are occasionally made, but recorded by my team for 'legacy' configurations. Is there a way to configure the output so you're told what encryption protocols the highest level protocol can be downgraded to? I.e. from TLS 1.2 to 1.1? Or is this not feasible currently?

Thanks again!

[nabla-c0d3]

Thanks @rdegraaf :).
@Theory5 it is not feasible currently but you could write your own custom logic by either using sslyze as a Python module (you can look at api_sample.py) or by parsing sslyze's XML output.
Good luck!

[meshach007m]

not supporting TLS_FALLBACK_SCSV is not necessarily a serious issue, depending on how well the client and server implement TLS 1.0 (by not supporting SSL 3.0 you already avoid the most glaring problems). However, good implementations cannot be guaranteed, and not supporting TLS_FALLBACK_SCSV is formally a weakness, even if it is not necessarily a vulnerability. That the weakness cannot be turned into a full exploit by attackers does not mean it does not exist.

In any case, you won't implement TLS_FALLBACK_SCSV because you want security; you will implement TLS_FALLBACK_SCSV because you want an A+. If you do not, then you will spend inordinate amounts of time explaining to many people that the "A+" grade is meaningless in that respect and that you can afford not to take it. In the long term, not howling with the wolves is too expensive.

The detailed description for the above said can be read from "https://security.stackexchange.com/questions/112531/is-tls-fallback-scsv-useless-if-only-tls-1-0-1-1-1-2-is-supported" which was answered by Tom Leek