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'.
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'?
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
In my understanding (I am not an expert), the attack really boils down to two high-level steps:
2. Run a chosen-plaintext attack from that position.
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)
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.
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!)
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.
I realize that the security industry is built on hype, but this is fucking dumb.
Nevertheless, if BEAST is basically an exploit on the Bard attack that's been known for years, perhaps it suggests that there was an insufficiency of hype around the original publication.
I obviously have no way to know whether this is a big deal or not. These guys have a "proven track record" from the ASP.net thing, but remember that attack came after a number of less-than-earth-shattering releases from them around padding oracles in other circumstances.
These guys need to publish the details now. Let the baby be born and not try to prolong the delivery for their own personal reasons.
So, that attack is less valid because it was gradually developed. That phrase doesn't make any sense.
But the real question: why do people pay so much attention to this here at HN? Why does it gets discussed as if would be given for a fact when all we have are rumors?
I think people just like to talk vaguely about crypto, throwing a few concepts and hypothesis around migt be enough for many to feel intelligent...?
I find you own attitude on the mater as a security researcher rather unprofessional. I beleive you are speculating hardly on this not being a serious matter, and are in fact as detail-less as the journalists hyping this up.
For the past 8 years TLS was know to be theoretically insecure and yet the fix was not widely adopted. I would have hoped we had outgrown ignoring "academic" issues with crypto systems after the debacle with non provably secure RSA signatures in SSL/the Bleichenbacher attack that necessitated OAEP in the 90s.
Maybe the security community deservers the world it lives in where this kind of hype is acceptable and productive? Certainly it could have been avoided by paying attention to these issues in the first place.
If this turns out to be somewhat accurate, a workaround could be to have the browser force the HTTP headers to be block-aligned, by inserting a dummy first header if necessary.
1. A user opens any HTTP website like http://google.com/ in Iran (for example)
2. Government-controlled Iranian ISP intercepts HTTP traffic and injects some rogue JS code.
3. Rogue JS code opens https-AJAX-connection to https://gmail.com/ and transmits some constant nonsense there (chosen plaintext attack).
4. The key point of TLS 0.x-1.0 vulnerability is deterministic calculation of IV in all sessions except first one. Initialization vector (IV) is computed using (pseudo)random numbers for the first session, and subsequent connections to the same website use new IVs computed with deterministic algorithm from previous IVs, without using random numbers.
It's a specific form of key integrity probably intended to counteract partial MitM. Or at least that way it was thought in 1994 by Netscape.
5. Rogue Iranian ISP intercepts resulting https traffic for https://gmail.com/ and by comparing known (chosen) plaintext versus ciphertext, computes initial IV. Here is where the novelty of the research is: popular belief in 2006 was this computation requires 2^1000 operations, in 2011 it turns out that could be handled in 10 minutes [see my remark below].
6. User navigates to https://gmail.com/ to read email. Browser chooses new IV different from old one, but Iranian ISP can compute it independently because algorithm is deterministic and previous IV is known to them.
7. By knowing second IV, Iranian ISP is able to decrypt all https traffic of the second session and extract user cookies from it. (Not necessarily in real time.)
8. Now Iranian government is able to read user's email by substituting his cookies on any computer and navigating to https://gmail.com/.
You may replace Iranian govt in this story with your neighbour in public WiFi, equipped with enhanced version of FireSheep.
My remark: I think this is fixable on the client side and somehow related to low-entropy PRNG used to generate IV for the first TLS session.
One way to think about it though is that CBC mode "sort of" uses the previous ciphertext block as the output of a PRNG which is used to randomize the plaintext before it's encrypted with the block cipher. However, the way TLS 1.0 uses it, the attacker is able to learn the output of that PRNG well in advance of when it can be used. If he can choose some plaintext during that time, this adaptive chosen plaintext attack is made possible.
They do not need to find an exploit in your browser to jump from an insecure browser session to your secure sandbox beside it.
More information at http://permalink.gmane.org/gmane.ietf.tls/8822
They still require access to your browser to, I'm assuming, modify certain data in some way such that they can actually perform the chosen plaintext attack on the encrypted cookies.
The researchers said that the browser-based attack is just one variant. They said they also could implement a similar attack against other services that use SSL, such as instant-messaging clients or VPNs."
Please read the article before flaming it.
Duong and Rizzo said the underlying vulnerability BEAST exploits is present in virtually all applications that use TLS 1.0, making it possible to apply the technique to monitor private communications sent through many instant messenger and Virtual Private Networking programs.
I know, why not just use https:// ? But it's hard to train users to act a different way and understand what's going on under the hood when they leave out a single letter in the protocol prefix. Just giving them a new address which they type in verbatim anyway seems like an easier fix. Plus, you disable all unencrypted connections for that domain and you don't need to worry about complex attacks like the current one and previous ones.
But besides that, as I understand it, this attack doesn't require an HTTP request to the victim site; it only requires an HTTP request to any site, followed by an HTTPS request to the victim site, so STS wouldn't be much help here unless all websites turn on SSL and adopt STS. (Though someone should correct me if I'm wrong.)
I could have read that draft wrong but it looks like it depends on headers from the victim site to determine if all traffic should be encrypted. MitM would defeat this.
Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [18.104.22.168])
(using TLSv1 with cipher AES128-SHA (128/128 bits))
Let's say an ISP in an oppressive country is hooked up to a government system which sniffs all traffic. It's able to record all your SSL traffic but is unable to decrypt it since it doesn't know the session key that was used for encryption.
 I'm guessing it takes the form of a GET request to non-existent resources. You know part of the input, and the resulting 404 page is almost always the same so you know part of the output.
However, it seems likely that other variations may surface as more people start to think about it.
What's that and how do I make the phone stop talking out loud