How much protection is really offered by TLS_FALLBACK_SCSV?

Question

I'm researching the extent to which TLS_FALLBACK_SCSV protects against Cipher Suite Downgrade attacks. I understand that the correct way to protect is to remove support for the insecure cipher suites. This is why I'm a little confused by results from ssllabs that give a nice green notice even though the server in question gets an F :

This server supports TLS_FALLBACK_SCSV to prevent protocol downgrade attacks.

This seems misleading to me. My understanding is that if the client (usually the browser, but also WEB-DAV, SVN, SQL clients, and others) doesn't support it, then the TLS_FALLBACK_SCSV flag does nothing. From reading this about IE, It seems like instead of implementing SCSV, some browsers just opted to remove SSLv3 support.

Also, TLS_FALLBACK_SCSV protects against some downgrade attacks but not all, apparently.

I'm told that my browsers are all protected from POODLE type downgrades but not against LogJam type downgrades.

So, is that reassuring Green Bar on ssllabs misleading?

Answer 1

I'm researching the extent to which TLS_FALLBACK_SCSV protects against Cipher Suite Downgrade attacks. I understand that the correct way to protect is to remove support for the insecure cipher suites.

TLS_FALLBACK_SCSV is about protocol downgrades and not about cipher suites downgrades. Don't confuse this with Logjam where the the cipher suite gets downgraded. Protocol downgrades can be fixed if you disable the protocol on the server but then you might get problems with older clients which do not support the newer protocol. That's why TLS_FALLBACK_SCSV was introduced to protect the newer browsers supporting this flag while maintaining compatibility with older browsers, even though they don't get the fallback protection.

My understanding is that if the client (usually the browser, but also WEB-DAV, SVN, SQL clients, and others) doesn't support it, then the TLS_FALLBACK_SCSV flag does nothing.

You are right that TLS_FALLBACK_SCSV is only relevant with clients which do support this option, which includes at least Chrome and Firefox. But to make this option useful it needs to supported by both client and server: The client sets the flag if it downgraded the protocol because the better version did not work (i.e. use TLS 1.0 instead of TLS 1.2) and the server must complain if the client set this flag even though the server would have support the better protocol version.

So, is that reassuring Green Bar on ssllabs misleading?

This bar should not be interpreted as "safe against all kind of SSL protocol downgrades" but "safe against all SSL protocol downgrades which can be detected with TLS_FALLBACK_SCSV". And in no way it should be read as "safe against all downgrades" because it explicitly mentions protocol downgrades (and not cipher downgrades like Logjam).

It seems like instead of implementing SCSV, some browsers just opted to remove SSLv3 support.

Both Chrome and Firefox use TLS_FALLBACK_SCSV to indicate SSL downgrade and also have SSLv3 disabled by default. Since there were reports of some TLS stacks being affected by POODLE even with TLSv1 and since there might be some other protocol downgrade attacks in the future unrelated to SSLv3 and since clients might have the need to re-enable SSLv3 for compatibility with some sites it is good to have this option anyway.

...a nice green notice even though the server in question gets an F

It should be clearly indicated why you get an F. You can do a lot of things right (like supporting TLS_FALLBACK_SCSV) and still get an F because you are using a self-signed certificate which can not be verified by the browsers.

And SSLLabs does not indicate a 100% secure site. Even with a grade of A+ it only indicates that you used the state of the art settings for setting up SSL/TLS but in a year these setting might no longer be state of the art because the state of the art changed while your site did not. This happened with deprecation of SHA-1, RC4 etc.