Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
mitigate BEAST #1460
I don't think this is still an issue for modern browsers. See https://security.stackexchange.com/questions/32817
I don't believe there's much we can do about this without Heroku, even if we needed to. If you're concerned enough, we could submit this to Heroku and ask them what, if anything, they are doing. My suspicion is they'll reply that its no longer an issue. Don't keep this ticket open too long.
Hey all --
[Responding with my Director of Security @ Heroku hat on.]
tl;dr: you don't need to worry about BEAST. It's not a practical attack. Automated scanners that pick it up are outdated and/or mistaken.
Here's the long version:
Heroku doesn't not consider BEAST to be a practical attack. The main reasons for this are:
Indeed, we're not the only ones saying that BEAST is no longer a threat. Qualys, a leading security and compliance firm, has come to the same conclusion, and they're no longer scanning for BEAST as part of their audit or PCI/HIPAA/etc. compliance work.
So what about Safari and older browsers (e.g. pre-2011 IE)?
Well, In order for the attack to work, the attacker must XOR the last ciphertext block of the previous message in the TLS session against the IV used for the ciphertext they're trying to decrypt, and then XOR the resulting block against what their best guess is at the underlying plaintext they want to recover. Once those three blocks are XOR'd together, the attacker then has to get the browser to transmit said block. In a more traditional "I have to get the browser to make a request" type attacks (i.e., CSRF), the attacker can simply insert <img>, <post>, or <iframe> tags (among others). However, those result in the first few bytes sent being "GET /" or "POST /". There's no general way for an attacker to get control over those first few bytes, and no way to compensate.
In the BEAST paper, they did this by man-in-the-middle'ing a plaintext (http) page under eBay, injecting a malicious SWF into that page, and using Flash's URLRequest mechanism. This worked, whereas regular tags didn't, because URLRequest gives the attacker total control over the bytestream. The BEAST paper [ http://blog.tempest.com.br/static/attachments/marco-carnut/driblando-ataque-beast-com-pasme-rc4/ssl_jun21.pdf ] mentions a number of different browser features that can be used for that (cross-domain XHR, Flash, Silverlight, HTML5 Web Sockets, and certain Java applet features).
However, all of these (including the attack in question) depend on a cross domain policy being relaxed enough to grant one or more http (plaintext) pages full access to request & receive arbitrary data from the victim https website. For XHR and WebSockets, that's CORS headers served up by the victim domain over https. For Flash, Silverlight, and Java, that's a crossdomain.xml file (or the Microsoft equivalent), also served up by the victim domain over https. Such a configuration, one that allows plaintext HTTP pages to make and read arbitrary requests to HTTPS pages in and of itself is enough to make the HTTPS pages vulnerable to man-in-the-middle attacks (a prereq for BEAST). Any attacker would simply modify the plaintext page to slurp down data directly from the HTTPS page that way, rather than go through the far more complex steps of BEAST to recover data one byte at a time.
So, again, we don't consider BEAST to be practical, and we recommend you also stop caring about it :)