It is recommended, to mitigate POODLE, if SSLv3 cannot be disabled entirely, to make use of TLS_FALLBACK_SCSV, a signaling cipher suite value that indicates that fallback has occurred. The draft standard for it says:
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 an inappropriate_fallback alert.
The idea, as I understand it, is that if the client has tried and failed to negotiate a connection with, say, TLS 1.2 (possibly because a MITM has forced this situation in a protocol downgrade attack), the server will be able to detect the situation because this signaling value will be present in the list of cipher suites.
I am not very familiar with TLS negotiation, and I do not understand why it would not simply be possible for the attacker to also manipulate the list of cipher suites to remove this signaling value?
For example, the client attempts to connect to the server with TLS 1.1, but Mallory the MITM intercepts and fakes a failure. And does so again when the client attempts to connect with TLS 1.0. When the client attempts to connect with SSL 3.0, Mallory strips TLS_FALLBACK_SCSV from the cipher suites, and passes the request on to the server, and then passes the server's response back, allowing the connection to be negotiated without the server ever seeing the FALLBACK indicator?
What features of TLS prevent such an attack? Is the list of cipher suites encrypted somehow, even before the session has been negotiated?