4 ms·

I happen to know the details of this attack since I work on Chrome's SSL/TLS stack. The linked article is sensationalist nonsense, but one should give the auth

by agl 15y ago

I happen to know the details of this attack since I work on Chrome's SSL/TLS stack. The linked article is sensationalist nonsense, but one should give the authors the benefit of the doubt because the press can be like that. Fundamentally there's nothing that people should worry about here. Certainly it's not the case that anything is 'broken'.

marshray 15y ago
But http://eprint.iacr.org/2006/136 http://eprint.iacr.org/2006/136 sure looks like a real attack to me. OpenSSL had released mitigations for it in the past but had to turn them off for compatibility reasons. Duong and Rizzo claim to be able to work out the session cookie in a few minutes from a network level MitM and they have come through on their promises before. How does this add up to nothing being 'broken'?
alecco 15y ago
This is a very real and serious attack. The IV weakness of SSL looks very scary. This MitM attack very feasible over wifi/corporate networks. For example, (simplifying a lot): * Initial shopping session example.com (HTTP) * User proceeds to payment stage payment.com * Browser with auth cookie for SSL payment.com * payment.com redirects to success page at example.com HTTP * Attacker MitM success page adding HTTP iframe to payment.com * Attacker serves fake iframe with JS code * The iframe has same-origin to payment.com * iframe does thousands of carefully crafted ajax/form requests to SSL payment.com * Optional 1: attacker snoops those requests/response to hint JS iframe * Optional 2: attacker blocks those requests * Since it's local MitM thousands of requests can be fired in seconds The attacker could use specially crafted URLs at https://payment.com https://payment.com and headers using XMLHTTPRequest.setRequestHeader() for the known plaintext.
- jacques_chester 15y ago
  The iframe injection reminds me of cookiemonster. In my understanding (I am not an expert), the attack really boils down to two high-level steps: 1. Gain a foothold in the browser to inject javascript. 2. Run a chosen-plaintext attack from that position.
  - 9ec4c12949a4f3 15y ago
    If you can inject javascript, why would SSL matter anyway? Everything's gone already.
anologwintermut 15y ago
Fundamentally is precisely the wrong word to use here. It may be the case that this particular attack is not an issue -- I doubt it given the authors track record -- but the paper marshray links to is an actual real issue even if this particular practical exploit of it is flawed. Fundamentally, TLS 1.0 is not secure ( formally INDCPA II). The correct thing to do is use something that is secure. Allegedly, TLS 1.1+ fits this bill (if one trusts Hugo Krawczyk proof that assumed fresh IVs). Anyone working on an SSL/TLS stack should be working to get this supported and should know enough to realize that supposedly theoretical issues with crypto systems can quickly become real easily (e.g, bleichenbacher's attack against ssl in the 90s)
agl 15y ago
> Certainly it's not the case that anything is 'broken'. Since others have found the links to the prior papers I don't have to worry about revealing anything by suggesting that there's prior work. What I was trying to hint at (badly) while still giving the authors their presentation, is that there's a long history behind this. Any weaknesses in TLS 1.0 should be credited correctly (and I'm sure the authors will do so), but it makes me feel bad that it's getting lost in the coverage so far. There might be a neat demo on Friday (I don't know the details of that) but they didn't break anything themselves.
- marshray 15y ago
  Note: I now have a draft of their paper but haven't read it yet. I think it's open at this point that BEAST is substantially based on Bard 2004/2006. What's not clear is how much they've improved upon it. This is important for more than just assigning credit, it's important so we can decide how much resources to invest in reviewing the severity all over again. * Rizzo and Duong have produced a working exploit. This is something Bard did not do. It's one thing to show something is possible and let the world forget about it soon after. It's another thing entirely to actually do it. * Bard's papers, especially the first one, spends too much time talking about trojan browser plug-ins and Java applets. This minimizes the fundamental attack. Obviously a user who installs a browser plugin is pwned in far simpler ways than this. * Rizzo and Duong have made some important improvements to the attack. It looks like Bard was heading in that direction in 2006 but did not get all the way. R&D are better at manipulating the underlying HTTP. (Of course they need to go ahead and go public with the details already!)
  - deleted 15y ago
    [deleted]
- willvarfar 15y ago
  Broken is when an attacker can decrypt your gmail without a fake cert. That's broken. Are you saying that TLS 1.0 is not broken? Sounds like instead you are saying that it's been broken for so long that this isn't breaking news. But "broken" as in "breaking news" is not at all how anyone parsing your initial post would grok it.

by agl 15y ago

marshray 15y ago

But http://eprint.iacr.org/2006/136 http://eprint.iacr.org/2006/136 sure looks like a real attack to me. OpenSSL had released mitigations for it in the past but had to turn them off for compatibility reasons. Duong and Rizzo claim to be able to work out the session cookie in a few minutes from a network level MitM and they have come through on their promises before. How does this add up to nothing being 'broken'?

alecco 15y ago

This is a very real and serious attack. The IV weakness of SSL looks very scary. This MitM attack very feasible over wifi/corporate networks. For example, (simplifying a lot): * Initial shopping session example.com (HTTP) * User proceeds to payment stage payment.com * Browser with auth cookie for SSL payment.com * payment.com redirects to success page at example.com HTTP * Attacker MitM success page adding HTTP iframe to payment.com * Attacker serves fake iframe with JS code * The iframe has same-origin to payment.com * iframe does thousands of carefully crafted ajax/form requests to SSL payment.com * Optional 1: attacker snoops those requests/response to hint JS iframe * Optional 2: attacker blocks those requests * Since it's local MitM thousands of requests can be fired in seconds The attacker could use specially crafted URLs at https://payment.com https://payment.com and headers using XMLHTTPRequest.setRequestHeader() for the known plaintext.

jacques_chester 15y ago
The iframe injection reminds me of cookiemonster. In my understanding (I am not an expert), the attack really boils down to two high-level steps: 1. Gain a foothold in the browser to inject javascript. 2. Run a chosen-plaintext attack from that position.
- 9ec4c12949a4f3 15y ago
  If you can inject javascript, why would SSL matter anyway? Everything's gone already.

anologwintermut 15y ago

Fundamentally is precisely the wrong word to use here. It may be the case that this particular attack is not an issue -- I doubt it given the authors track record -- but the paper marshray links to is an actual real issue even if this particular practical exploit of it is flawed. Fundamentally, TLS 1.0 is not secure ( formally INDCPA II). The correct thing to do is use something that is secure. Allegedly, TLS 1.1+ fits this bill (if one trusts Hugo Krawczyk proof that assumed fresh IVs). Anyone working on an SSL/TLS stack should be working to get this supported and should know enough to realize that supposedly theoretical issues with crypto systems can quickly become real easily (e.g, bleichenbacher's attack against ssl in the 90s)

agl 15y ago

> Certainly it's not the case that anything is 'broken'. Since others have found the links to the prior papers I don't have to worry about revealing anything by suggesting that there's prior work. What I was trying to hint at (badly) while still giving the authors their presentation, is that there's a long history behind this. Any weaknesses in TLS 1.0 should be credited correctly (and I'm sure the authors will do so), but it makes me feel bad that it's getting lost in the coverage so far. There might be a neat demo on Friday (I don't know the details of that) but they didn't break anything themselves.

marshray 15y ago
Note: I now have a draft of their paper but haven't read it yet. I think it's open at this point that BEAST is substantially based on Bard 2004/2006. What's not clear is how much they've improved upon it. This is important for more than just assigning credit, it's important so we can decide how much resources to invest in reviewing the severity all over again. * Rizzo and Duong have produced a working exploit. This is something Bard did not do. It's one thing to show something is possible and let the world forget about it soon after. It's another thing entirely to actually do it. * Bard's papers, especially the first one, spends too much time talking about trojan browser plug-ins and Java applets. This minimizes the fundamental attack. Obviously a user who installs a browser plugin is pwned in far simpler ways than this. * Rizzo and Duong have made some important improvements to the attack. It looks like Bard was heading in that direction in 2006 but did not get all the way. R&D are better at manipulating the underlying HTTP. (Of course they need to go ahead and go public with the details already!)
- deleted 15y ago
  [deleted]
willvarfar 15y ago
Broken is when an attacker can decrypt your gmail without a fake cert. That's broken. Are you saying that TLS 1.0 is not broken? Sounds like instead you are saying that it's been broken for so long that this isn't breaking news. But "broken" as in "breaking news" is not at all how anyone parsing your initial post would grok it.