15

With the alleged SSL/TLS vulnerabilities used by the BEAST exploit, there seems to be a security gap between TLS versions; TLS 1.0 being the problematic one but still the only option for many sites.

If indeed there is a problem with older TLS versions, what measures should we take, at the user end, in order to prevent possible attacks? I would think that a browser plugin to report the TLS version and allow connections only when safer versions are used would be very useful, but haven't been able to find one yet.

Any other suggestions, practical tips etc.?

Andrei Botalov
  • 5,317
  • 10
  • 46
  • 73
George
  • 2,813
  • 2
  • 23
  • 39

4 Answers4

6

Until the security hole is closed both ends (web server and browser software) it will be hard to prevent. Unfortunately because the current exploit targets cookies you have minimal control over it client-side. The only exception is to change your encryption ciphers and block or reorder CBC ciphers to the least preferable so it has the least likelihood of being used for SSL/TLS communication.

See http://support.microsoft.com/kb/245030 and http://blogs.technet.com/b/steriley/archive/2007/11/06/changing-the-ssl-cipher-order-in-internet-explorer-7-on-windows-vista.aspx for how to do this on Windows.

I would suggest that the best thing you can do before a client-side fix is available is education and awareness. Including:

  • Log out of websites when not in use, instead of just closing the browser.
  • Don’t save login credentials.
  • Find out what your trading partners are doing to implement tighter security controls on their web sites.

I guess it also important to note that not all websites using legacy SSL/TLS versions are affected. While the transport security part (SSL/TLS) is, there may be other anti-spoofing techniques in place to reduce the impact of information disclosure.

Stay tuned, be ready to deploy newer browser versions, and no doubt there will be more news soon but hopefully some fixes.

Bernie White
  • 2,856
  • 17
  • 18
  • The list of things I have to educate my users about just became longer. Very soon they'll have to be "aware" of so many things they'll be awarded CS degrees... – George Sep 26 '11 at 07:07
  • @Georgios Indeed. Also note that IE9 and IE8 do support TLS 1.1 and 1.2. IE9 it is on by default. IE8 is not but can be enabled. The caveat to that is that IE cipher support is provided from Secure Channel (SChannel). This means that Windows XP with IE8 can not support TLS 1.1/1.2. If you are running Windows 7 and Windows 2008 R2 no problem. – Bernie White Sep 27 '11 at 03:07
  • It is unclear yet if Microsoft might actually be forced to implement TLS 1.1 or 1.2 in Windows XP SP3 because it is still in Extended Support. http://technet.microsoft.com/en-us/security/advisory/2588513 – Bernie White Sep 27 '11 at 21:26
3

from the way this exploit is supposed to work as a MitM from inside the browser attacking via blockwise-adaptive chosen-plaintext cryptanalysis.....

the current and only solution (limited-security) I can think of (until Browsers & Servers are patched to work with newer versions... gonna take time) is Browsing all your secure sessions from an independent browser (remember not a different instance but a different browser) not used for your usual web-surfing, even any links in your mails and all need to be copied and opened in different browser; also use AdBlocker & NoScript browser plug-ins.

This should safeguard to a great extent. Anyway, this is a good practice for secure sessions, with or without this exploit.

http://hackersmag.blogspot.com/2011/09/beast-beating-ssl-tls-what-you-can-do.html

For a better understanding of the BEAST, you could have access to the SSL Paper for it and the Java Code at http://www.insecure.cl/Beast-SSL.rar

AbhishekKr
  • 563
  • 3
  • 4
3

You can't solve this without your browser vendor's assistance. Communicate with your browser vendor to indicate that you would like to see support for TLS 1.2. (There is probably a bug report already in their bug tracker; probably you can just vote for it, and monitor it, to see when a new version of the browser is available with support for TLS 1.2.)

Then, wait.

What needs to happen is: (1) browsers roll out support for TLS 1.2, (2) web sites roll out support for TLS 1.2. Both of these will take time. In addition, there has been a bit of a chicken-and-egg situation, where browsers don't prioritize supporting TLS 1.2 since no sites support it, and sites don't prioritize supporting TLS 1.2 since browsers don't support it.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • 3
    It's worse than that - browsers need to offer TLS 1.1/1.2 *and* need to NOT accept downgrade to SSL3. Servers, likewise, need to turn on TLS 1.1/1.2 *and* disable support for SSL3. Simply getting both sides to *enable* TLS 1.1+ is not sufficient without simultaneously turning off SSL3. – Steve Dispensa Sep 26 '11 at 17:38
  • Good point, @Steve. Thank you! (Nitpick: I think disabling SSL3 is only necessary to stop MITM attacks; if you're only worried about eavesdropping, just enabling support for TLS 1.1+ on both sides should be enough.) – D.W. Sep 26 '11 at 18:44
1

For now, Eric Rescorla recommends disabling Java as a work-around. He has a long post that explains why, but the short version is that Duong and Rizzo's latest demonstration of the exploit involves use of Java. There is no guarantee that this is the only way to exploit the attack, but it appears to be the only practical way currently known. Also, you should make sure your browser is up-to-date. Read Eric Rescorla's long blog post for an explanation.

Caveat: Folks are still gathering information about the attack. This advice may change as more information becomes available.

D.W.
  • 98,860
  • 33
  • 271
  • 588
  • Disable Java? The exploit uses JavaScript which has nothing to do with Java. In a Web 2.0/3.0 world no decent site will work without JS. To defeat this, change your cipher to RC4 –  Apr 26 '12 at 05:56
  • 2
    @GideonKimbrell, apparently, the exploit uses Java (or can be used with Java). EKR's blog talks about `URLConnection`. – Bruno Apr 26 '12 at 10:54
  • @GideonKimbrell, hello and welcome to Security StackExchange. Please keep the discussion on an objective level instead of a personal one. – Hendrik Brummermann Apr 26 '12 at 11:08