4

I've been following POODLE and the SSL_MODE_SEND_FALLBACK_SCSV TLS extension. I never really paid much attention to it, but it appears SSL_MODE_SEND_FALLBACK_SCSV is needed for clients like browsers which attempt to use a particular SSL/TS protocol version, and then fallback to a lesser version on failure.

SSL/TLS effectively has a 'min' and 'max' version set during the handshake, and those values are MAC'd so that downgrade attacks are remediated.

It seems to me that client software which probe and fallback are defective since they suffer downgrade attacks. If they used the protocol as designed, this particular problem would not exist and there would be no need for SSL_MODE_SEND_FALLBACK_SCSV.

Additionally, SSLv3 is now deemed insecure, so SSL_MODE_SEND_FALLBACK_SCSV is not needed since no one will be using it (as if Loren Weith didn't enumerate the problems with SSLv3 clearly enough).

Why does client software, like web browsers, probe for a particular protocol version and fallback on failure?

13

Client software that is susceptible to downgrade attacks is defective, in the sense that it purposely does things outside of the standard in order to support server software that is defective.

Normally, the client announces (in the ClientHello) its highest supported protocol version number (e.g. "3.2" to mean "TLS 1.1") and then the server responds (in the ServerHello) with the protocol version that will be used for that connection. Therefore, the theoretical behaviour when a recent client talks to an old server is the following:

  • Client says: "I support up to 3.2".
  • Server thinks: "Mmh, I have no idea what SSL 3.2 may be, but I know SSL 3.0 and 3.0 is less than 3.2".
  • Server responds: "We will use 3.0".

However, in some rare cases in practice, old server software is not only old but broken; and things go that way:

  • Client says: "I support up to 3.2".
  • Server thinks: "OMG 3.2 I HAVE NO IDEA WHAT THAT IS I MUST COMMIT HONOURABLE SEPPUKU". Server closes the connection abruptly.
  • Client thinks: "Mmh, the server broke. Probably an old piece of junk. I must use patience when I speak to the elderly".
  • Client reconnects and says: "I support up to 3.0".
  • Server responds: "We will use 3.0".

When things go that way, the hash that is computed over all handshake messages and included in the Finished messages does not include the fact that the client could have used a newer protocol. By reconnecting and using an artificially lower announced version, the client prevents the downgrade detection system from working. We can say that the problem occurs because the clients don't act as they should, but they do so because there are deployed servers that are even more broken. It can be hard to unambiguously lay blame here.

Attackers who want to force a protocol downgrade abuse that system by killing the first connection with a well-placed RST packet, so as to simulate a senile server that cannot tolerate any of this newfangled talk about a protocol version other than 3.0.

The TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks extension, currently in draft, is a method for sneaking in the handshake message the information that the client really supports better than SSL 3.0, in a way that won't make old servers scatter their electronic brains on the floor; it takes the form of a special cipher suite identifier (it is based on the idea that even old broken servers will not go berserk when the list of supported cipher suites includes one that they do not know). Of course, the mechanism brings any protection only if both the client and server are aware of it (the client must put the special identifier, and the server must recognize it and say to itself: "how come we are doing SSL 3.0 if the client knows a newer version? This is fishy...").

Another view on the subject is that if SSL 3.0 is weak and should not be used at all, then the only sane practice is to reject it altogether. You need a protection against downgrade attacks only if you are still ready to use SSL 3.0 in case the server truthfully supports nothing else. If you fear the consequences of using SSL 3.0, then you should never accept to use it. This is considered as potentially extreme; a smoother compromise may be, on the client (browser) side, to maintain an explicit list of servers for which SSL 3.0 will be tolerated. Such a list, configurable by the user himself, combines possible tolerance of a few legacy systems, and a healthy dose of finger-pointing at the systems whose misery should have been ended long ago.

Edit: see the comments there; this is a discussion between Firefox maintainers where they discuss exactly the consequences of dropping SSL 3.0 support altogether, and various alternatives.

  • "However, in some rare cases in practice..." - so why break security for 99% of the use cases. Require user who need this particular feature to download a plug-in to provide the feature. Browsers did the same to me (and other users) who would like a browser to open a homepage. Arguably, opening a home page is more prevalent than supporting 20 or 25 year old servers. – jww Oct 17 '14 at 17:51
  • 3
    As a rule, software vendors don't want to maximize security; they want to minimize bad press. – Thomas Pornin Oct 17 '14 at 18:57
  • @jww I know a few major vendors that have software (still under support) that will hung under a TLS1.1 or 1.2 hello and others that would just simply break apart. It is not as uncommon as you would think. They just don't add support to TLS1.1 or later on "old" software, even if they do relase updates for it. And that is if you stick to WEB Servers. You would cry if asking for SSL/TLS support for other software: stuck with SSLv2 and v3 with low ciphers, impossibility of using keys over 1024, "tricks" to make Java secure (more than 56 bit ciphers) outside USA, etc. – NuTTyX Oct 17 '14 at 21:43
  • Actual support for TLS 1.1 and later however is different from performing the TLS version negotiation correctly. – Yuhong Bao Dec 4 '14 at 10:26
1

Short version: interoperability sucks.

Long version:

Currently there are four SSL/TLS variants in common use:

  • SSLv3 (1996)
  • TLSv1.0 (1999)
  • TLSv1.1 (2006)
  • TLSv1.2 (2008)

Each protocol supports a variety of ciphers. Older protocols have wider, more uniform cipher support. Newer protocols may implement smaller subsets of the ciphers available, and different clients and servers may implement different subsets in all cases. As time goes by, it becomes more obvious which ciphers are common, and implementations will increasingly support common ciphers (sort of the chicken and the egg all rolled up together).

Therefore - older protocol versions are more likely to share a common subset of acceptable ciphers.

The idea of fallback is that two systems may try to speak together on TLSv1.2, but be unable to agree upon a cipher. By saying it's okay to fall back and try an older protocol, the chances of being able to negotiate an acceptable connection improve. Clients can try for the best security, but fallback allows interoperability.

(And, remember, there should not be any insecure protocols on the list. SSLv3 just took a major hit to it's security - you can expect it to disappear from common use within the next year).

  • Why don't browsers provide a sane list of 15 or 20 cipher suites using TLS 1.0 and above? Its 2014 for christ sake. I mean, they make me download a damn plugin just to open my homepage (opening a home page should be built-in browser functionality). In the same thinking, require folks who want 25 year old downlevel functionality to download a plugin to provide or enable it. – jww Oct 17 '14 at 17:36
  • 1
    @jww Well, there are those old F5 load balancers that break when the ClientHello is 256-511 bytes... Modern cipher suites, session resumption, NPN and ALPN caused browsers to start hitting that problem. (F5 fixed/is fixing the problem, and people invented a new padding extension to increase the ClientHello to 512+ bytes -- which also causes interoperability problems with other servers.) – Matt Nordhoff Oct 18 '14 at 4:09
  • 1
    Tongue-in-cheek serious answer aside, I disagree with @gowenfawr. Current TLS implementations are pretty uniform and good; interoperability problems are caused by old implementations that don't support anything secure. TLS is designed to negotiate features quite well; fallback is needed because of old implementations that have bugs in their negotiation. – Matt Nordhoff Oct 18 '14 at 4:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.