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."

Comments

Re:TLS 1.1 or 1.2?

[wisesifu]

Its not the only the browsers that need to support the newer versions of these protocols, but also the servers.

Acronym hell

[Chrisq]

Having looked up "1.2. FTFA" on google I now feel like a complete idiot

All the more reason to use a VPN

[jkbull]

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.

Re:All the more reason to use a VPN

[ledow]

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.

Speculation on the attack

[dachshund]

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

Re:TLS 1.1 or 1.2?

[Anonymous Coward]

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.2 were enabled on the client side. I tried it anew yesterday just out of curiosity, and now even Opera 11.51 chokes on TLS 1.1 and 1.2. So there. Nothing really supports the protocols. Must wait for OpenSSL 1.0.1 for TLS 1.1 and nobody knows when that will hit the repos.

Re:TLS 1.1 or 1.2?

[Kjella]

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:TLS 1.1 or 1.2?

[dachshund]

Its not the only the browsers that need to support the newer versions of these protocols, but also the servers.

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

And my speculation on how the attack works, in detail:

http://practicalcrypto.blogspot.com/2011/09/brief-diversion-beast-attack-on-tlsssl.html

Solutions without TLS v1.1 and v1.2

[tmshort]

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.