Slashdot Mirror
Google Prepares Fix To Stop SSL/TLS Attacks
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."
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?
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Having looked up "1.2. FTFA" on google I now feel like a complete idiot
So....how long before they update BEAST?
No sig today...
If you use a VPN, you should be protected from "local" man-in-the-middle (MITM) attacks. By "local", I mean between your computer and the VPN server. A VPN doesn't protect you from a MITM attack between the VPN server and the webserver you are connecting to. But it does protect you to the VPN server if you are at an Internet cafe, hotel, or other untrusted network.
At least that's true for most VPNs that use software based on OpenVPN, which uses OpenSSL for encryption. A copy of an email from James Yonan was recently posted to the OpenVPN User's list. Bottom line of the email: OpenVPN uses OpenSSL for encryption, and OpenSSL has been patched since 2002 for the vulnerability which most people think is exploited by BEAST. As long as your VPN software uses a patched version of OpenSSL you should be covered, at least for the "local" MITM attack.
For example, VPNs based on Tunnelblick, a free and open source GUI for OpenVPN on Mac OS X is not vulnerable.
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
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.
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 most people are not protected.
New things are always on the horizon
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
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:
- close the browser (all existing HTTPS-connections are thus closed)
- open the browser
- only open a tab/window to the HTTPS-site and don't forget to type https:/// infront of it
- and use that
- when you are done
- logout on the site
- close the browser
Works fine with SSL/3.0 or TLS/1.0
Because what the attacker needs to do is through some other channel inject plain-text into the stream you are using to connect to the HTTPS-site.
The man-in-the-middle attacker does this by modifying a page loaded over HTTP that you loaded on a different page.
If all you have open is the one site, they can not do that.
New things are always on the horizon
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 fine as I understand it (haven't checked)
4. A fairly recent Apache with mod_ssl (which uses OpenSSL) like the one in Debian stable supports TSL/1.1, the previous stable does not. Debian stable also has the option to use mod_gnutls instead, it supports TLS/1.2
5. it has to be enabled on the server for it to work, this is the problem with IIS. It is off by default as I understand it (haven't checked)
New things are always on the horizon
You're ignorant.
You're welcome.
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.
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 (!)
New things are always on the horizon
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 it. It can't use it.
We should probably just agree to disagree.
New things are always on the horizon
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 random amount of padding adds randomness to the known plaintext, in a manner similar to, but different than, Google's solution.
4. Use HTTP/1.0. The suspected attack vector requires a long-term TLS connection that is reused by the browser. HTTP/1.0 allows one request per connection. Each connection will use different key material. This means that BEAST's JavaScript request will have different keys than the user's request. This is easily configurable on the server, and requires no changes to the client (unlike solutions 1-3).
The trade-off is that all these options slow down the connection to some degree.
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
And: http://httpd.apache.org/docs/2.2/mod/core.html#serversignature
Or, if it's even Apache at all, consider: http://forum.lighttpd.net/topic/3887
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 disabled specific protocol versions. (ie, Apache/1.3.42 (Unix) mod_perl/1.31 could probably be compiled against libssl 1.0.0 or 0.0.6 for all you know. Assuming it's not lighttpd configured to lie.)
The only way to know what version of SSL/TLS is supported is to connect and ask for decreasing versions until one is accepted.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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 SSL libraries and disabled/enabled protocols in the server configuration.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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 version, or a server that normally supports TLS1.x could have TLS1.x disabled manually, or a server could use an alternate library like apache+gnutls (which supports TLS1.1 and 1.2) instead of apache+openssl (which does not). The only way to know for sure is to connect directly to the server and try different versions to see which are accepted.
If I have been able to see further than others, it is because I bought a pair of binoculars.
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.
If I have been able to see further than others, it is because I bought a pair of binoculars.