19

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?

Community
  • 1
David Conrad
  • 301
  • 3
  • 10
  • 1
    A related question, with more info, but which did not answer my question: http://security.stackexchange.com/questions/70988/why-do-browsers-probe-and-fallback-or-why-ssl-mode-send-fallback-scsv – David Conrad Oct 20 '14 at 17:58
  • Crossdupe http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks although I think here is the better fit. – dave_thompson_085 Jul 13 '16 at 01:56

2 Answers2

17

At the end of the handshake, Finished messages are exchanged, under the protection of the newly negotiated algorithms and keys; in particular, the contents of these messages are protected by a MAC. The contents of the Finished messages are a hash of all preceding handshake messages. Any external manipulation of the ClientHello message as it transits from client to server will be detected at that point: the client and the server won't work over the exact same ClientHello contents, thus won't obtain the same hash value for the Finished messages.

This protects the handshake against alteration as long as whatever alterations the attacker performs don't allow him to immediately break the whole crypto layer. In the case of the Poodle, even if the attacker succeeds in forcing SSL 3.0 usage, he cannot destroy the crypto right away, and thus cannot "fix" the Finished messages.

Tom Leek
  • 170,038
  • 29
  • 342
  • 480
7

While not strictly a duplicate of How does SSL/TLS work?, the answer is there:

The Finished message is a cryptographic checksum computed over all previous handshake messages (from both the client and server). Since it is emitted after the ChangeCipherSpec, it is also covered by the integrity check and the encryption.

If you alter any portion of the handshake in the middle, you will invalidate the entire handshake, and the connection will be aborted.

Community
  • 1
gowenfawr
  • 72,355
  • 17
  • 162
  • 199
  • Thank you. I think there may be an additional wrinkle that Tom covers in his last paragraph that makes this not strictly a dupe, but I'm reading over that other question and answer now, and if you think my question should be closed as a dupe I would understand. – David Conrad Oct 20 '14 at 18:06