Hacker News new | past | comments | ask | show | jobs | submit login

The attack works in such way:

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.

It's not session resumption that is the problem - even when TLS sessions are resumed, new connections still generate new keys. Rather, it's new requests on the same HTTPS connection (HTTP keepalive). The problematic predictable IV is at the start of each HTTPS record within a single connection.

So if this is a problem with subsequent IVs, wouldn't turning off SSL session caching server side mitigate the attack as well? Highly loaded servers wouldn't be able to handle this, and it degrades the experience for high-latency users, but it does force a new session on every connection.

This description of the attack suggests a stream of ajax requests to a site to detemine the PRNG. Does that mean that it would be possible to create rainbow tables (or equivalent) for all common implementations of the PRNGs, or certainly for targeted sites e.g. banks, PayPal etc etc?

No, it's not an attack on the PRNG in the usual sense.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact