Is TLS_FALLBACK_SCSV going to be the fix for servers that wish to keep SSLv3 enabled? If not what actions are being taken, if any, that address the vulnerability besides disabling SSLv3?

  • SSLv3 is still reasonably safe when using RC4.
    – nwellnhof
    Commented Oct 21, 2014 at 18:36

2 Answers 2


SSLv3 protocol is flawed. This cannot be fixed. Generally, an attacker would exploit this by forcing the victim to connect to a server using SSLv3 by forcing connections using higher protocols to fail. TLS_FALLBACK_SCSV attempts to stop the browser/server from falling all the way back to SSLv3 if a higher protocol has already been tried.

As you can see, TLS_FALLBACK_SCSV doesn't actually fix the protocol issue, but instead tries to reduce the attack surface by making it harder for the attacker to force the victim to protocol downgrade.

TLS_FALLBACK_SCSV will have no effect if either the browser or server do not support anything higher than SSLv3 (which is rare, I grant you, but not impossible).

  • You say "attempts to stop". This implies that it could fail. You also say that it "reduces the attack surface". Can you provide examples of how this would fail if enabled and being used both client and server side?
    – user53029
    Commented Oct 21, 2014 at 11:18
  • Currently, no, I can not. However, I'm not a dedicated attacker. It's counter productive to assume that the protection will be perfect. Commented Oct 21, 2014 at 11:35
  • Since SSLv3 is flawed, wouldn't the only sane option be to skip the protocol entirely? I.e. if that's the highest protocol the server supports, drop the connection?
    – Clearer
    Commented Oct 21, 2014 at 18:21
  • @Clearer, possibly, but then you run risk of having no way for the client to connect to your site. This is bad for both customer and company. The customer can't buy his goods, and the company can't sell their goods. Commented Oct 22, 2014 at 7:30
  • @ChrisMurray i.e. hurry up and tell people to upgrade their security and upgrade your own so we can get rid of buggy protocols.
    – Clearer
    Commented Oct 29, 2014 at 21:49

There have been some discussions about mitigating issues with some record splitting. Namely, what makes Poodle efficient is that padding may use up to a full block (8 bytes with 3DES or RC2, 16 bytes with AES). When this happens, only the last byte of the block is checked by the recipient, which is why the alteration from the attacker gets through with probability 1/256. Thus, if you can arrange for that padding situation never to happen, then you can reduce the success probability of the attacker.

The idea is then, when a record is to be encrypted and would lead to a final block with too much random padding and too few non-ignored bytes, to split the data into two records, whose individual lengths will induce last blocks with sufficiently few ignored padding bytes.

This "fix" is discussed there (see in particular comment 13). Attacker's success drops from 1/256 to 1/281474976710656. However, this only applies to Poodle as it was described; and it is known that record splitting, though "legal" from the standard point of view, may break old, buggy, legacy implementations.

TLS_FALLBACK_SCSV dos not fix SSL 3.0; it fixes protocol downgrade attacks. It ensures that if the client and server both know TLS 1.0+, then they won't be forced to use SSL 3.0. However, if the client or the server knows only SSL 3.0, then the communication will use SSL 3.0, and Poodle attacks may apply. This is unavoidable: if the server knows only SSL 3.0, then the choice is between using a Poodle-vulnerable protocol, or not communicating at all.

A number of people have expressed that they would prefer the latter. Rather than tolerating SSL 3.0 with either TLS_FALLBACK_SCSV or some record splitting, just let it die. It will have to happen at some point; the general concern triggered by a vulnerability may be a good occasion for that.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .