Google Prepares Fix To Stop SSL/TLS Attacks 122
OverTheGeicoE writes "It was reported Tuesday that researchers had found a way to break the most commonly used SSL/TLS encryption in browsers. According to the Register, Google is pushing out a patch to fix the problem. The patch doesn't involve adding support for TLS 1.1 or 1.2. FTFA: 'The change introduced into Chrome would counteract these attacks by splitting a message into fragments to reduce the attacker's control over the plaintext about to be encrypted. By adding unexpected randomness to the process, the new behavior in Chrome is intended to throw BEAST off the scent of the decryption process by feeding it confusing information.' The fix is supposedly in the latest developer version of Chrome."
TLS 1.1 or 1.2? (Score:2)
Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?
Re:TLS 1.1 or 1.2? (Score:4, Insightful)
Re:TLS 1.1 or 1.2? (Score:5, Informative)
Maybe not. It appears that OpenSSL in 0.9.6d implemented a "fix" to TLS 1.0 that may not require a change to the server. The basic idea is that the browser injects message prefixes into the stream as a kind of "fake" IV, to keep the Javascript from having control of which messages get encrypted. This may stop the attack.
Furthermore, if the prefixes are formatted in a certain way --- total speculation --- it may be possible to get the server to filter them out even if it's not running the same software. Anyway, I can't imagine how OpenSSL would implement this fix if the servers don't support it. But I admit I'm just catching up on this aspect.
Here's a brief post describing the "fix":
http://article.gmane.org/gmane.network.openvpn.user/32566 [gmane.org]
And my speculation on how the attack works, in detail:
http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html [blogspot.com]
Re: (Score:1)
Re: (Score:2, Interesting)
Will you kindly explain to the unwashed masses how you would implement TLS 1.1 and 1.2 support in a world where the dominant library OpenSSL does not yet support either of the protocols in its stable releases? Sure, you can use GnuTLS and mod_gnutls, and I have tried it, but there was no point, as no browser apart from Opera supported it and there were some weird glitches in the module. IE 8/9 were supposed to support them under Vista and 7, but failed to access the site served by mod_gnutls when 1.1 and 1.
Re: (Score:2, Informative)
AC said it, the standard may be many years old but no released version of OpenSSL supports anything higher than TLS 1.0....
Re: (Score:1)
Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?
Surprisingly hard, because there is still around 1-2% of HTTPS servers that are not compliant with the TLS protocol specification and reset the connection when a client attempts to negotiate a version higher than they can understand. Usually in these cases TLS 1.1 means too high, client developers are mainly just waiting for the broken servers to disappear or get upgraded before they can turn on the switch and start using new TLS versions. TLS 1.2 is also a bit different from TLS 1.1, and TLS 1.0 for that m
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
Except, of course, the customers don't do that. They simply figure this is one of the endless list of pointless natter comfirmations computers bombard them with, and click on it until it goes away.
Re: (Score:2)
Or, if they have one or two braincells working on critical thinking, they'll wonder and worry, call the support site for the organization whose server they're trying to use, and get told (after waiting on hold for several hours) "that warning doesn't mean anything; your connection is as private and secure as it always has." And that will be that.
If we're gonna hypothesize some kind of public groundswell in support of long-delayed technological deployments, can we get it behind IPv6 first? kthxbye.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
The general opinion is that the LGPL bars distribution of a statically linked binary containing non-GPL family code combined with LGPL code.
You might be able to get away with providing object code for both your binary and the library, but that makes RMS sad.
Re: (Score:2)
There are many many servers that will totally fail if the client claims to support TLS 1.1 or 1.2.
Re: (Score:2)
Could clients detect this somehow and fall back to support the broken behaviour? For example on detection of an unexpected reset.
Re: (Score:1)
Re: (Score:2)
The point of the fix is that a whole lot of servers are now invulnerable to this.
(Hopefully the important ones).
Re: (Score:2)
Re: (Score:2)
Presumably the client could warn the user...
Re: (Score:1)
Re: (Score:2)
But if you have to renegotiate down to 1.0 because the server does not support it, you are still vulnerable.
Both browsers and servers should both be updated to support TLS 1.1 and 1.2, and both browsers and servers should negotiate the most secure, mutually supported protocols and cyphers.
Adding that support will take some time, and it will take years to lose the old clients that aren't updated (Win XP with IE 6 still has another 2+ years of support, for example). But if we don't start adding support now with backwards compatibility so that nothing breaks then we're never going to get the newer protocols.
Is b
Re: (Score:2)
Re: (Score:3)
Could clients detect this somehow and fall back to support the broken behaviour? For example on detection of an unexpected reset.
Yes, but it opens you up to downgrade attacks. If both the client and server claims to support protocol X then it should not be possible to force them to use protocol Y which is considered less secure, even if both support that too. If you have a fully working TLS 1.1/1.2 client and server then all I have to do is cause a reset, the client will think it's a broken server and they'll use TLS 1.0 so you create a vulnerability where there was none.
Re: (Score:2)
Call me ignorant here, but how hard would it be for people to enable TLS 1.1 or 1.2 support in browsers and sites, since that apparently isn't vulnerable?
I think it would be hard for them to do this quickly. The Google Chrome solution is really a stopgap until then.
Re: (Score:2)
Ignorant (Score:2)
You're ignorant.
You're welcome.
Re: (Score:2)
You forgot the "here", but thanks for the effort!
Re: (Score:2)
Thanks for asking the question though. It was my first thought when I read the /. summary. I learned a bit from the answers.
Re: (Score:2)
Indeed. Slashdot may have gone down in recent years and have a bit of a reputation for trolls and shills, but if you know how to navigate through the comments, it's still a golden source of insight, information and the occasional bit of wit. This comment thread shows that..
Acronym hell (Score:3)
Re: (Score:2)
Re: (Score:2)
Um, none of those are acronyms, they're initialisms.
See: http://lyberty.com/encyc/articles/abbr.html [lyberty.com]
Re: (Score:2)
Are they initialisms, though? Do you read "FTFA" as "eff tee eff ay" or "from the f*king article" ? Most people I know do the latter, which means its not an initialism either.
Re: (Score:2)
Re: (Score:1)
"throw BEAST off the scent" (Score:2)
So....how long before they update BEAST?
Re: (Score:2)
They'll have to try a completely different approach.
Smart workaround, I didn't know this was possible without changes on the server side.
All the more reason to use a VPN (Score:2)
At least that's true for most VPNs that use software based on OpenVPN, which uses OpenSSL for encryption. A copy [gmane.org] of an email from James Yonan
Re:All the more reason to use a VPN (Score:4, Interesting)
I found out all that information for myself separately before you posted that, but it's interesting to see the problem. I had to make the same assumption that the attack described is actually the one that was published all those years ago, which is pretty likely at this stage.
To summarise: Web browsers tend to use the NSS libraries, which have a "bug". The bug is subtle and actually part of the TLS 1.0 standard, but a tiny, standards-compliant, workaround virtually fixes the problem.
It's the same bug that OpenSSL patched 9 YEARS ago, fully knowing what they were patching and based on a publicly available paper on attacking exactly what NSS/OpenSSL were designed for (so the name "Network Security Services" is a bit of a misnomer now). The workaround is pretty basic (throw empty junk into the conversation first) but by all accounts "works".
A lot of browsers use NSS and thus are vulnerable. Some don't and thus aren't (Opera uses OpenSSL which was patched against this 9 years ago!). The "fix" that Google have committed to Chrome is basically identical to the OpenSSL fix from all those years ago.
The bug was pretty much unforeseeable all that time ago, and thus TLS 1.1 etc. were born to supplant it. You can't really blame people for the bug existing in the standard - you CAN blame them for not fixing it 9 years ago when others did exactly that, in "open" code.
Lessons to be learned:
1) SSL library authors needs to READ publicly available exploits aimed at the code they are developing.
2) They need to read other project's bug/commit-logs/security warnings if they are serious about being a competitor to their security.
3) Don't use libraries that don't do the above if you want to be taken seriously, and certainly not in a mainstream millions-of-deployments browser.
4) Update your libraries and recompile your code when they change.
OpenSSL know what they are doing and have a good reputation. NSS are pretty much amateurs. Think of that next time you want to use an SSL library.
Re: (Score:1)
Speculation on the attack (Score:5, Informative)
I had posted this in another thread, but in case it's helpful --- this is my best guess on how the attack works in detail:
http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html [blogspot.com]
Confusing it? Really? (Score:1)
That doesn't sound like a "fix" as much as it sounds like a "bandaid."
It doesn't counteract the root functionality of the exploit. It simply reduces the chances of it being successful.
It's like changing your windows password every day and calling that "invulnerable security" simply because someone is less likely to be able to guess it.
Re: (Score:1)
Although it has not been fully disclosed yet, it's my understanding that the attack is only practical because of a sort of implicit "trust chain" in the implementation of TLS 1.0 where knowledge of one block gives you all the information you need to decode the next block... but also that proper decryption of one block means that you know that you decrypted the previous block successfully. That's the kicker - if you are just making guesses at one block but know the contents of the next block, the encrypted r
Solutions without TLS v1.1 and v1.2 (Score:2)
Based on what is known about this attack, there are a number of ways it can be thwarted without the need for TLS v1.1/v1.2.
1. Google's solution: by randomly sizing the TLS records, this adds randomness to the known plaintext through more frequent padding.
2. OpenSSL's solution of refreshing the IV by adding an empty TLS record - but some MS products have issues with this.
3. TLS v1 permits up to 255 bytes of padding. Most implementations add the minimum amount (up to 7 for 3/DES and 15 for AES). Using a rando
Re: (Score:2)
Could the server use compression and randomly vary it and not do optimal gzipping for the content?
Re: (Score:1)
It's apparently an issue with the client-sent data - that is the data that is analyzed. BEAST has no control over the server-sent data, so whatever the server does, short of closing the connection, has no effect.
Re: (Score:2)
Can clients send compressed data to servers?
Re: (Score:1)
Strictly-speaking, I don't believe so. There's no way to negotiate the compression method. In the case of the server sending data, the client is able to indicate acceptable compression algorithms (via Accept-type headers) before the server sends the data (with Content-Encoding headers indicating compression). With the client sending data first, there's no way for the server to tell the client what is acceptable.
SSL does have support for compression, but there are no compression methods defined other than NU
Re: (Score:2)
Somebody please mod this up.
Re: (Score:2)
It is only solved for those websites that also support TLS/1.1 and/or TLS/1.2.
There is no GUI which displays what the server supports so you don't really know.
Also like IE8 or IE9 on Vista, Windows 7 and Windows 8 preview-or-whatever-it-is-called it is disabled by default.
As I understand it is disabled by default on IIS too.
Apache on Debian old-stable does not support TLS/1.1 on Debian stable it does. It is enabled too. You can get TLS/1.2 as well, if you install mod_gnutls instead of mod_ssl
So in practise
Re: (Score:2)
That does not help, it does not show what version of HTTPS it supports.
The way to check HTTPS versions/protocol features and so on is at:
https://www.ssllabs.com/ssldb/analyze.html?d=slashdot.org&s=216.34.181.45 [ssllabs.com]
This is what it says on the page:
TLS 1.2 No
TLS 1.1 No
But it obviously still does not tell you if _you_ are connected to a server with supports it and if client and server are using it right now.
Trust me, most don't support it.
The best and most simple way to make sure you are safe is:
- clos
Re: (Score:2)
Actually you don't, here is a short list of things from the top of my head:
1. there could be a HTTP-reverse proxy in front handling the HTTPS, so even if the HTTP-header inside the HTTPS instream says it used webserver X. It does not mean your browser is talking directly to that HTTP-server
2. Even if it says: Apache it might not say what version.
3. For Apache it depends on the version of the OpenSSL-library installed and the options need to be enabled. For Debian a default install of Debian stable should be
Re: (Score:2)
Yes, but what does a Google query tell you about the website (thus server) you are connecting to ?
The Google query tells you certain versions of Apache do support TLS/1.1 and TLS/1.2.
It does not tell you the Apache of the website you are connecting to has that version of Apache installed.
Even if it did, it does not tell you what version of OpenSSL is installed. You can compile a new version of Apache with an old version of OpenSSL just fine. And people do (!)
Re: (Score:2)
The point I'm trying to make is, the version number of a webserver does not mean that TLS/1.1 or TLS/1.2 will actually be used when your browser connects to it.
As I pointed out before, as an example:
IIS (the Microsoft webserver on Windows Server) has the ability to use TLS/1.1 and TLS/1.2 but it is not enabled by default.
Just that case makes it pretty clear that a version number alone does not tell you anything.
It doesn't matter if your browser support TLS/20.234 or whatever, if the server does not support
Re: (Score:2)
Netcraft can only tell you what the server is configured to tell it.
See: http://httpd.apache.org/docs/2.2/mod/core.html#servertokens [apache.org]
And: http://httpd.apache.org/docs/2.2/mod/core.html#serversignature [apache.org]
Or, if it's even Apache at all, consider: http://forum.lighttpd.net/topic/3887 [lighttpd.net]
Finally, even if you had the version of apache and the server wasn't lying to you, it's the OpenSSL and/or GNUtls library version you'd need to know to actually find out what's supportable, and that still doesn't tell you if the admin
Re: (Score:2)
Actually, I do know because of Opera... & THERE IS (again) A "GUI TOOL" FOR IT, BUILT INTO OPERA, NATIVELY.
So your browser connected to the server itself and checked specifically for the supported protocol versions, just like I said. Did it really take three replies to agree with me?
I was simply pointing out that you can't tell just from a server version string because the server version string can be faked, and even when it's not faked, it still doesn't tell you enough information about the supporting
Re: (Score:2)
I never said anything about whether you were insecure or not. The only thing I said was that it was not possible to determine the version of SSL a site uses simply by looking at the server version string, which is what you implied here:
Because the server can lie about its versio
Re: (Score:2)
So now we're back to where you agreed with me and you're using tools that connect to the server and try different protocols to see which ones work instead of trying to google for the server name to guess what versions might be supported.
Re: (Score:2)
thnx for the link.
on page 1 it says:
BEAST is like a cryptographic Trojan horse - an attacker slips a bit of JavaScript into your browser
how does it do that? and more importantly how can I as a user check if this piece of javascript code is running in my browser (firefox).
do you have any further details on this? thnx.