This repository has been archived by the owner. It is now read-only.

mitigate BEAST #1460

Closed
chadwhitacre opened this Issue Sep 15, 2013 · 6 comments

Comments

Projects
None yet
4 participants
@chadwhitacre
Contributor

chadwhitacre commented Sep 15, 2013

BEAST is a vulnerability in TLS 1.0, which is what Heroku is running. How do we mitigate this? Can we? Or are we dependent on Heroku here?

This was reported by @Kudu in IRC, and again today by @adamziaja (http://adamziaja.com) in private email.

@seanlinsley

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Sep 15, 2013

Contributor

I don't think this is still an issue for modern browsers. See https://security.stackexchange.com/questions/32817

Contributor

seanlinsley commented Sep 15, 2013

I don't think this is still an issue for modern browsers. See https://security.stackexchange.com/questions/32817

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Sep 15, 2013

Contributor

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.

Contributor

mvdkleijn commented Sep 15, 2013

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.

@jacobian

This comment has been minimized.

Show comment
Hide comment
@jacobian

jacobian Oct 3, 2013

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:

  • All major browsers, with the exception of Safari, now implement record splitting on the client side, which makes them completely immune to BEAST.
  • We could implement record splitting on the server, but that would break a bunch of older clients, particularly in the mobile/embedded space. We believe, then, that server-side record splitting would cause more harm than good.
  • The standard recommendation to prevent BEAST has been to prioritize RC4 ciphers, which we also believe is more harmful than helpful. RC4 has had a number of cryptographic weaknesses discovered over the last few years. The general consensus seems to be that RC4 is either broken already or very near to it, so most crypto pros are now strongly recommending against its use.

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 :)

jacobian commented Oct 3, 2013

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:

  • All major browsers, with the exception of Safari, now implement record splitting on the client side, which makes them completely immune to BEAST.
  • We could implement record splitting on the server, but that would break a bunch of older clients, particularly in the mobile/embedded space. We believe, then, that server-side record splitting would cause more harm than good.
  • The standard recommendation to prevent BEAST has been to prioritize RC4 ciphers, which we also believe is more harmful than helpful. RC4 has had a number of cryptographic weaknesses discovered over the last few years. The general consensus seems to be that RC4 is either broken already or very near to it, so most crypto pros are now strongly recommending against its use.

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 :)

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Oct 3, 2013

Contributor

@whit537 I'm taking the liberty to close this issue based on the remarks of @jacobian on behalf of Heroku and based on our earlier estimates it wouldn't be a problem anymore.

Contributor

mvdkleijn commented Oct 3, 2013

@whit537 I'm taking the liberty to close this issue based on the remarks of @jacobian on behalf of Heroku and based on our earlier estimates it wouldn't be a problem anymore.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Oct 3, 2013

Contributor

@mvdkleijn I'm comfortable closing. Thanks. Could you merge #1531 as well?

Contributor

chadwhitacre commented Oct 3, 2013

@mvdkleijn I'm comfortable closing. Thanks. Could you merge #1531 as well?

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Oct 3, 2013

Contributor

@whit537 Done. 😄

Contributor

mvdkleijn commented Oct 3, 2013

@whit537 Done. 😄

mvdkleijn added a commit that referenced this issue Oct 3, 2013

Merge pull request #1531 from gittip/BEAST-ack
Acknowledge researchers re: BEAST ticket #1460
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.