The POODLE attack announced very recently depends largely on a protocol downgrade attack (which I covered in my SSL/TLS presentation at BSides). I don’t think this aspect of TLS security was widely appreciated – but it is now! It’s a fair bet that any technical article about POODLE includes the phrase “TLS_FALLBACK_SCSV” as a remedy. This article discusses the mechanism proposed to protect us from attackers forcing TLS downgrades. NEW (16/10/14): while I was writing this I thought of a small but potential compatibility problem, which in fact could do us all a favour. I checked with the authors of the RFC and Adam Langley was kind enough to reply back so I’ve added added a new section below.

TLS_FALLBACK_SCSV is a fake cipher suite advertised in the Client Hello, which starts the SSL/TLS handshake. SCSV stands for “Signaling Cipher Suite Value”. The idea of using a cipher suite as a signal is not new: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is a way clients can advertise that they support secure renegotiation (addressing CVE-2009-3555):


The RFC for the TLS_FALLBACK_SCSV mechanism is still a draft but apparently Chrome (and Google from the server-side) has been using it since February 2014. This is no surprise as the RFC was written by two Google heavyweights. (Perhaps this was written with POODLE in mind as the RFC and the attack share an author – but that’s pure speculation!)

The whole business of successively downgrading the protocol version was put in place because browsers wanted to ensure they could connect to servers that were buggy. The TLS_FALLBACK_SCSV mechanism ensures that this downgrade only happens with the client’s blessing.

How does the protection work?

TLS_FALLBACK_SCSV is recommended for a client to indicate that it is knowingly repeating a SSL/TLS connection attempt over a lower protocol version than it supports (because the last one failed for some reason). When the server sees a TLS_FALLBACK_SCSV signal it compares the highest protocol version it supports to the version indicated in the Client Hello. If the client’s version is lower, then the server responds with a new Alert defined by the RFC called inappropriate_fallback. The idea being that the server knows the client supports something better so the connection should have negotiated that. The inappropriate_fallback Alert is a “fatal” error, i.e. the SSL/TLS connection is aborted.

Why does this help against POODLE?

Let’s say both the client and server support TLSv1.2. The client starts off, hoping to make a TLSv1.2 connection but an active man-in-the-middle attacker interferes with the handshake in the hope of forcing a downgrade. By repeatedly doing this, the attacker can force the use of SSLv3 and try some shenanigans like POODLE. Remember, the attacker can’t remove the TLS_FALLBACK_SCSV from the Client Hello because the handshake is cryptographically protected (unlike in SSLv2).

After the first round of interference, the client should try TLSv1.1. With the TLS_FALLBACK_SCSV signal in place, the server will pick up on the fact that the client is only requesting a TLVs.1.1 connection because of some difficulty earlier on. The server now knows that there is no good reason why a connection with a higher procotol version should have failed – and duly aborts the current connection.

The attacker could, of course, drop the TLSv1.1 and the following TLSv1.0 Client Hello. If the lack of response causes the browser to downgrade again then eventually the browser will try a SSLv3 connection, which the attacker will let through. Again, the TLS_FALLBACK_SCSV signal indicates to the server that the client supports something better and will terminate the connection attempt.

Okay, what if the client doesn’t support the server’s best protocol (TLS v1.2 in this example)? Just to be clear, let’s consider that case. The client would begin with, say, a TLSv1.0 connection. The attacker interferes with the handshake and so the client tries a SSLv3 connection with TLS_FALLBACK_SCSV. Again, the server knows that the client is only doing this because an earlier attempt with a higher protocol failed so it returns the Alert and the downgrade is aborted. If the client tries again, unhindered by the attacker, the client’s opening TLSv1.0 request is accepted because it lacks the TLS_FALLBACK_SCSV signal.

It’s more than just a POODLE buster…

The TLS_FALLBACK_SCSV mechanism doesn’t just protect us from attacks to downgrade connections to SSLv3: it protects us from forced downgrades completely. So when we want to connect using TLSv1.2, we can be sure that a meddling attacker can’t drop us down to TLSv1.0, which doesn’t support the best available cipher suites. As ever, we do need the server to play along.

…but it’s not quite a silver bullet

Of course, TLS_FALLBACK_SCSV doesn’t help if the best protocol version is SSLv3 at the client and SSLv3 is supported by the server – or vice versa. In this case SSLv3 will be agreed so no downgrade attack is required but the attacker still needs to make the browser perform multiple requests to the target domain, as the whitepaper explains. Remember that the attack only works with block ciphers operating in CBC mode so if the preferred cipher suite over SSLv3 is RC4 then the attack is likely to fail. Not that I’m advocating SSLv3 with RC4 as a solution though!

If SSLv3 is disabled either on the server or the client, POODLE has lost its bite. The only practical reason to support SSLv3 for servers is to humour IE6 users (because IE6 doesn’t enable TLSv1.0 by default). But if that’s a must then TLS_FALLBACK_SCSV – when supported by both client and server – will protect the vast majority of connections when SSLv3 isn’t necessary.

UPDATE: OpenSSL 1.0.1j supports TLS_FALLBACK_SCSV.

NEW: Assumptions and side effects

While writing up these scenarios I thought of a potential compatibility issue when TLS_FALLBACK_SCSV was in place. The draft RFC states that the connection MUST be refused by the server if the maximum protocol version the server supports is higher than the one advertised in the Client Hello with the TLS_FALLBACK_SCSV signal. This assumes that the server supports all protocol versions in between the client’s stated version and the server’s maximum. What can the server infer about the client? It’s clear the client supports at least a protocol version one higher than that in the Client Hello. But that’s all the server knows. So what if one of those intermediate versions isn’t supported by the server and happens to be the highest version the client supports?

In previous pentests I have seen servers that don’t support TLSv1.1 but do support TLSv1.0 and TLSv1.2. Imagine a client that supports TLSv1.1 at best and so it starts off a TLSv1.1 connection. TLS allows for the server to respond saying effectively “sorry, can’t do that, I can do TLSv1.0″. But supposing it’s one of those buggy servers that the downgrade fallback was intended for…In this case the connection fails in an unexpected way and the browser attempts the connection again, this time using TLSv1.0 with the TLS_FALLBACK_SCSV signal. The server then refuses the connection as its maximum TLS version is 1.2 and it assumes the client can do better. But, in fact, the client doesn’t understand 1.2 and the server doesn’t want to talk 1.1. The two will never talk to each other.

I put this to the RFC authors and I was delighted that Adam Langley replied (on what must have been a particularly busy day!): “I think you’re correct that the server will break in that situation”. He also proposed another, simpler compatibility scenario: “a server believes that it implements TLS 1.2 but is buggy and doesn’t handle, say, the signature_algorithms extension correctly. It works currently because clients downgrade to TLS 1.1. If the server implements TLS_FALLBACK_SCSV then it breaks”.

But is this a problem? I guess it’s unlikely. I don’t know how many of these buggy servers are out there. It’s also a fair assumption that any server that has the awareness to support TLS_FALLBACK_SCSV has also got the TLS version negotiation working. What about from the client viewpoint? In the example above, according to Wikipedia older versions of Chrome and Opera supported TLSv1.1 at best but of course users of these browsers are now very likely to have been auto-updated to later versions. However, we want the TLS_FALLBACK_SCSV mechanism to be future-proof.

At the same, ultimately this is all the fault of buggy servers. Many browsers will look to disable SSLv3 in the light of POODLE, knowing that this will cause issues for a small number of sites but that’s a reasonable price to pay to protect the majority. Enabling TLS_FALLBACK_SCSV for the long-term good could be viewed in the same way. Adam Langley seemed to agree: “TLS_FALLBACK_SCSV is a way for good servers to lift themselves out of the swamp that buggy servers have created. If you have a buggy server and enable TLS_FALLBACK_SCSV then it could certainly break your server. Hopefully that’s noticed in testing and then the real bug can be fixed :) ”. That’s why, when he acknowledged the potential for compatibility issues, he added “but I’m ok with that”.

Implementing TLS_FALLBACK_SCSV could expose the buggy servers that fallback was designed for – and perhaps that’s just what we need.

6 thoughts on “POODLE and the TLS_FALLBACK_SCSV Remedy

  1. Pingback: What is POODLE and how to detect it | serializethoughts

  2. Darren Sandford

    Thanks! This is the clearest description of how TLS_FALLBACK_SCSV works, and more importantly it’s intention! Much appreciated!

  3. Rich

    Hi I am trying to open my cragslist account and I cant access the page. I would like to know If I should play with my ssl2 and3 settings or if I should get windows 8 ? I`m running xp home sp2 ie8 seems like the poodle problem thanks for any feed back richardpelzer@netzero.net

    1. Jerome Post author

      Organisations might well have disabled SSLv3 (and v2) but IE8 supports TLSv1.0 by default so there’s no obvious reason why that browser wouldn’t connect. Test the domain you’re trying to connect to at SSL Labs and see which protocols it supports. Also check the “handshake simulation” section and see what it reports for IE8 under XP.

  4. alex

    > Remember, the attacker can’t remove the TLS_FALLBACK_SCSV from the Client Hello because the handshake is cryptographically protected

    Could you explain by what means it is protected? There is now signature over Cipher Suites in Client Hello.

    1. Jerome Post author

      Before any data is sent, the client and server negotiate which cipher suite to use (as well as other parameters) before exchanging key material in such a way that they both end up with the same set of symmetric secrets, which a network man-in-the-middle can’t determine. At this point, the two endpoints check to see that the handshake hasn’t been tampered with by essentially hashing the previous Handshake* messages, which has encryption and integrity checking applied. Both the client and the server does this so, using their newly derived secrets, they can verify these Finished messages from each other, and thus they can be confident that the handshake has been negotiated without any funny business. In this way the handshake is protected.

      * there is a specific set of Handshake messages (consult the RFC): other non-handshake messages may have been transmitted but won’t be included in the making of the Finished message. The most “famous” exception is the ChangeCipherSpec (CCS) message, which precedes the Finished message. This is why the OpenSSL CCS vulnerability (CVE-2014-0224) could be exploited, as the attacker’s CCS messages are not included in the handshake verification.


Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>