25

TLS 1.0 seem to be vulnerable to Beast, Lucky13 and maybe other attacks and is simply outdated. Common workaround used e.g. by Google was to use RC4 which was also recently broken, but none of the major browsers seem to be implementing newer version of TLS, except Microsoft IE for newer Windows versions.

Is there a reason why there has been so little movement?

Edit: almost the same question. Why was it closed? Mystery on stackexchange.
Supported TLS versions at 2011-09-22


Do I think right that to avoid problems with TLS 1.0 you have to forbid it? This can take time.


I'll misuse my questions to answer Thomas Pornin because this doesn't fit into comment.

As usual, you write many letters :)

"RC4 breakage is still "academic"

Do you remember WEP history? 2001 only certain key patterns were vulnerable which could be excluded without changing the protocol, 2004 it was no more the case and 2007 only 40k packets were enough. Attacks never get worse, only better. And in real life, all updates need time, years will past till all servers update, although it's not so much like on soho routers. Can you predict with reliable probability when it will become realistic? About workarounds - are they backwards compatible? How long will they hold? Isn't it easier to use newer TLS version?

Upgrading client support to TLS 1.2 will not change anything at all until most servers are upgraded, too.

So upgrades need time, earlier we'll begin, earlier it's done.

comparison with IPv6

Well, with IPv4 you can predict when you are out of IPs. This depends much of the country - those who were first in internets usually have no problems :) Those who are out of IPs advance IPv6, like China.

In practice, several widely used browser rely on the SSL/TLS code of the underlying OS

Which ones O_o? I thought only IE does this, who cares about it with no working AdBlock.

4 Answers 4

26

The main reason why there is little movement is that the "breaks" are not practical enough to show up on radar.

  • BEAST does not work anymore. Firstly, it requires a way for client code in the browser (hostile Java or hostile Javascript) to emit cross-domain requests with a high level of control at the bit level; the two known ways to do that (a draft version of WebSockets, and a vulnerability in the Java VM implementation) have been fixed. Secondly, browsers and OS have added workarounds, namely the 1/n-1 split: whenever a TLS record is to be emitted, two records are sent, the first one containing only one byte of application data. This workaround prevents BEAST from being applied.

  • RC4 breakage is still "academic". It had been known for some time that RC4 had some serious biases. The recent results (March 2013) are some systematic measures which show that there are more biases than previously thought, so that an actual attack requires "only" observing a few millions of connections with the target secret always in the same place. While "a few millions" is rather low, it is still impractical, from the attacker's point of view, in a Web context. Thus, no cookie has been stolen in the wild through usage of RC4. Moreover, there are possible workarounds which are easier to implement in a browser.

Thus, there is no real incentive for a mass update of client TLS implementations. Indeed, browser vendors are accustomed to deal, on a weekly basis, with vulnerabilities which are much more devastating than that (typically entailing hostile hijack of the whole client system). A somewhat theoretical exploit of the cryptography in SSL is unlikely to be even noticed, let alone acted upon. What makes browser vendors move towards newer versions is the publicity which is made about these cryptographic attacks.

Moreover, and that's the important point, the protocol version which will be used for any given connection is constrained by what both client and server software support. Upgrading client support to TLS 1.2 will not change anything at all until most servers are upgraded, too. And, similarly, upgrading server support is not very useful until clients are upgraded. This is the classic Mexican stand-off, in which nobody moves, because it would require a massive simultaneous upgrade switch of several distinct vendors. For that matter, it is the same story as with IPv6 (which was scheduled for wide adoption in 2007).

In practice, several widely used browser rely on the SSL/TLS code of the underlying OS, so any mass upgrade will have to wait for the end-of-life of Windows XP (scheduled by Microsoft for next year).

1
  • See question update. Mar 21, 2013 at 7:34
22

I am not sure what you mean by not supported. Currently the following browsers support TLS 1.1 and 1.2:

  • Chrome - v30 supports TLS 1.2. Previous to this only up to TLS 1.1 was supported
  • Firefox - v27 enables TLS 1.1 and 1.2 by default
  • Internet Explorer - v11 supports TLS 1.2 from Feb 2013
  • Opera - v17 has added support for TLS 1.2. Versions 10-12 supported TLS 1.1 and 1.2 but disabled it by default, and versions 14-16 supported TLS 1.1 but not 1.2.
  • Safari - v5 on iOS and v7 on OS X have added support for up to TLS 1.2.
1
  • 5
    TLS 1.2 is disabled by default in IE 10 and Opera...
    – Andy
    Jun 29, 2013 at 8:53
5

BEAST has been fixed on modern browsers.

While people really should be moving to the newer TLS versions, there hasn't been a significant adoption of the newer protocols. There has been compatibility problems with servers that has not activated the newer protocols. See this link for more information. The article is almost a year old though, so there might have been improvements since that time.

One plausible reason for not shifting over to the newer TLS versions is that developers have been applying band-aids to the older protocols to fix any vulnerabilities is found. This obviously isn't sustainable in the long run. Hopefully the recent spate of attacks against SSL/TLS will push people to speed up the move to newer versions of the protocol.

4
  • <_There has been compatibility problems with servers that has not activated the newer protocols._> - you can still fallback to older versions. The problem is the clients. Mar 19, 2013 at 3:49
  • @SmitJohnth "Firstly, there's the usual problem of buggy servers. TLS has a version negotiation mechanism, but some servers will fail if a client indicates that it supports the newer TLS versions." From the article I linked to. Like I said, the article is a year old though, things should have improved somewhat since then.
    – user10211
    Mar 19, 2013 at 4:29
  • The link only talks about Chrome. Mar 21, 2013 at 7:28
  • I've heard that Lucky13 was not fixed. Mar 21, 2013 at 14:24
2

The reason Firefox does not support TLS 1.2 is because the security backend they use Network Security Services does not support it. An implementation is work in progress, see this bug report

Update: As of June 13, 2013 Chrome Canary now supports TLS 1.2 as the relevant bug is fixed now.

2

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .