POODLE and TLS_FALLBACK_SCSV deep dive

We’ve been seeing a lot of requests to implement TLS_FALLBACK_SCSV. Unfortunately, it only works if you already have clients that understand it. This article will give some background, discuss TLS downgrades and finally have some suggestions for what you can do now.

Background
Over the years, cryptographers have worked with Internet engineers to improve the Transport Layer Security (TLS) protocol. Each revision of the protocol provides improvements to defend against the latest attacks devised by the cryptographers.
 
In 2011, Thai Duong and Juliano Rizzo demonstrated a proof-of-concept for attacks against the way SSL/TLS use the Cipher Block Chaining (CBC) mode of encryption. Their paper introduced the Browser Exploit Against SSL/TLS (BEAST) and used it to demonstrate how a “man-in-the-middle” (MITM) with the ability to run Javascript on the victim client could generate many thousands of TLS sessions and eventually recover a session cookie.
 
The defense against the BEAST attack was included in TLS 1.1, but few web servers or clients migrated right away.

POODLE is a similar attack to BEAST, but works against SSLv3 due to the special structure of the padding in SSLv3. Part of the POODLE attack is a downgrade to SSLv3.

TLS Downgrades
TLS agents should negotiate the highest version of the protocol supported by client and server. Clients advertise the highest version of the protocol they support. The server selects the highest version it supports, and sends the negotiated version number in the ServerHello message.
 
Many broken TLS implementations in widespread use were unable to cope with versions they did not understand. This caused  large numbers of TLS sessions to break during the TLS 1.1 rollout.
 
The browser vendors implemented a downgrade mechanism. Immediately after a session fails during the initial handshake, the browser will retry, but attempt a max version one lower than before. After attempting to connect to a server with the max version set to TLS1.1, the client would retry with the max version set to TLS1.0.
 
Security researchers love automatic downgrades because they get to attack older protocols instead of newer, more secure protocols. A MITM attacker can break client connections during the initial TLS handshake, triggering a downgrade all the way to SSLv3.
 
Bodo Möller and Adam Langley devised Signaling Cipher Suite Value (SCSV) ,TLS_FALLBACK_SCSV, so the client can inform the server of a downgraded connection. It indicates to the server that the client had previously attempted to connect using a higher max protocol version, but the session was broken off before the initial handshake could be completed.


If the server sees the SCSV, and if it could have negotiated a protocol version higher than what the client is currently announcing as its maximum, the server must break the connection.
 
On October 21, Möller and Langley presented to members of the IETF TLS Working Group to lay out their rationale and argue for inclusion of the TLS_FALLBACK_SCSV draft in the upcoming revision to TLS.

 
The key points to their argument are presented on page 3:

  • Ideally, stop doing downgrade retries
  • If that’s not practical, clients should add TLS_FALLBACK_SCSV to ClientHello.cipher_suites in fallback retries
  • Servers that detect TLS_FALLBACK_SCSV will reject the connection if ClientHello.client_version is a downgrade

 
Möller and Langley implemented TLS_FALLBACK_SCSV in Chrome, Firefox, and Google servers earlier in 2014. During the past several months, they’ve had an opportunity to confirm that it allows SSLv3 connections only in cases where that is truly the highest common protocol version.

On October 15, OpenSSL for the first time integrated TLS_FALLBACK_SCSV code.
 
Upgrade your clients
The best protection against POODLE is to disable SSLv3. That is not always possible because of legacy clients.

Unfortunately, TLS_FALLBACK_SCSV requires both clients and servers to implement it. Legacy clients will not send TLS_FALLBACK_SCSV. You must update the clients to newer code to get all the advantages of TLS_FALLBACK_SCSV.

If you can update all your clients to code that supports TLS1.x, then you can successfully disable SSLv3 from your BIG-IPs using either method described earlier.

If you can’t upgrade your clients, you can avoid POODLE by using SSL3’s RC4 stream cipher instead of a block cipher with CBC. Be aware that there are known weaknesses in RC4.

Published Oct 22, 2014
Version 1.0

Was this article helpful?

4 Comments

  • Unfortunately, something is poorly documented. There is nothing to find about TLS_FALLBACK_SCSV in AskF5, except in the v11.5.1 HF6 RN: 485188 When the SSL ClientHello contains the SCSV marker, if the client protocol offered is not the latest that the virtual server supports, a fatal alert will be sent.
  • TLS_FALLBACK_SCSV support exists in the latest hotfix
  • Dustin_Plomondo's avatar
    Dustin_Plomondo
    Historic F5 Account
    There is an askF5 solution article now describing support for the SCSV in certain versions of Big-IP: SOL16935: Support for the TLS Fallback SCSV https://support.f5.com/kb/en-us/solutions/public/16000/900/sol16935.html