What does the SSL/TLS BEAST exploit mean for my web-based file transfer application?

Researchers have discovered a serious vulnerability in TLS v1.0 and SSL v3.0 that allows attackers to silently decrypt data that’s passing between a webserver and an end-user browser. This vulnerability can be exploited using a new cookie-based technique called “BEAST” (“Browser Exploit Against SSL/TLS”) that takes advantage of block-oriented cipher implementation such as AES and TripleDES.

Which file transfer protocols are affected?

Any interactive HTTPS-based web-based transfer application that relies on SSL/TLS will probably be affected.   Web-based “file send” applications will almost certainly be affected.  Web services that use cookies to maintain an authenticated session after sign on will also be affected.

At the moment it appears that only protocols that make use of browser cookies are affected.  That means that the FTPS and AS2 protocols are safe for now, even if they use TLS v1.0 or SSL v3.0.

SFTP and other protocols that use encryption not based on SSL/TLS are of course not affected by BEAST.

Which vendors are affected?

Just about ALL of them.  Any on-premise product or cloud-based product that:

  • allows end users to upload, download or send files through a web browser
  • AND uses an SSL/TLS-secured channel (i.e., uses HTTPS)
  • AND uses cookies (even memory-only cookies) to maintain user sessions after the initial sign on

…will probably be affected by this vulnerability.

What should I do now?

Our current recommendation is to:

  • CHOICE #1:
    • DISABLE TLS v1.0 support on your file transfer web interfaces
    • DISABLE SSL v.3.0 support
    • ENABLE TLS v.1.1 and TLS v.1.2 support
  • CHOICE #2:
    • DISABLE AES and TripleDES encryption support on your file transfer web interfaces
      • (as per this article, both AES and TripleDES are affected)
    • ENABLE RC4 encryption support
  • IN ALL CASES:
    • Keep SSL v.2.0 disabled
      • (you should have already done this years ago)
    • If you are using a managed file transfer gateway or proxy to terminate SSL/TLS sessions, remember to check those configurations too

Microsoft offers a similar recommendation here.

What will this mean for my end users?

If you apply our “CHOICE #1″ recommended configuration you will likely encounter some compatibility problems with end users whose web browsers do not support TLS v1.1 or v1.2.  To get around this issue you will need to have your users upgrade their browsers to editions that support TLS v1.1 (see partial list below) or have your end users use a different web browser.  (The latest version of Opera and IE both support TLS v1.1.)

If you apply our “CHOICE #2″ recommended configuration you will not be able to use your FIPS-valided AES or TripleDES algorithms on your SSL/TLS connections.  Rc4 is an older, secure but not FIPS-validated algorithm that is often used by browsers and servers by default.  (R6, R4′s successor, was a runner-up to become the new AES algorithm during the open competition about a decade ago.)  

Can you help us configure our file transfer software to mitigate against this threat?

Yes – please contact us for more information.

Where can I get more information about the vulnerability?

The Register has a good article on the vulnerability and BEAST here:
http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/

“BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their PayPal attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of (the researchers’) claim that this time can be drastically shortened.”

ThreatPost’s article also has additional detail:
http://threatpost.com/en_us/blogs/new-attack-breaks-confidentiality-model-ssl-allows-theft-encrypted-cookies-091611

“The decryption process is fast enough that it’s likely imperceptible users, and the researchers said that in a targeted attack, they likely could steal the cookie from a specific site within five minutes of loading the tool. Rizzo and Duong said that their attack exploits a vulnerability in the TLS 1.0 protocol that has been known for quite some time, but was thought to be unexploitable.”

What web browsers have been patched against this?

Opera is now patched!  (article)  It also supports TLS v1.1 – another fine choice!

IE is now patched! (article)

  • Google Chrome will soon have a BEAST patch ready (article)
  • Firefox has NOT yet promised a BEAST patch (article)
    • However, Oracle provided a Java plug-in patch for Firefox to make the most common exploit harder (article)
  • CANNOT FIND any information about Safari/Webkit recognizing BEAST (please send me links!)

A relatively fresh list of browsers that support more recent versions of TLS v1.1 is maintained here:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Browser_implementations

Currently only Opera (version 10 or higher) and IE (version 8 or higher on Windows 2008 R2 or Windows 7) are listed with TLS v1.1 support.  Firefox does not currently support TLS v1.1, nor does Chrome or Safari.   However pressure to add TLS v1.1 support to those browsers has increased substantially since BEAST was announced.

What are some of the servers that support TLS v.1.1?

Microsoft IIS 7 (on Windows 2008 R2) supports TLS v.1.1 but it must be specially enabled(This affects web transfer applications that rely on IIS such as Ipswitch’s WS_FTP Server Web Transfer Module, WS_FTP Server Ad Hoc Module and MOVEit DMZ.)

Many other file transfer vendors ship their own web servers with their products – check with your vendor for specific guidance.

About Jonathan Lampe

Andy White and I started File Transfer Consulting in 2011 to solve secure file transfer and managed file transfer issues through strategic analysis, training, integration and custom development. Our unique approach allows us to address complicated issues like no one else.

Before FTC I created and then led the development of Ipswitch's MOVEit managed file transfer software for ten exciting years, including three as VP for R&D and Product Management at Ipswitch (WS_FTP, MessageWay and hosted services). I also served for VP for Product Management for RhinoSoft (Serv-U), where I guided the development of managed file capabilities and marketing that led to its eventual sale to SolarWinds.

Come meet me on Google+ or LinkedIn today!