Can Poodle be fixed in SSLv3 or will it go the way of TLS compression?

Question

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?

Answer 1

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).

Answer 2

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.