11–20 of 137 posts
Doesn't look like this has anything to do with an exploit. It is because some older web servers who don't support TLS also don't support compression. See: http://code.google.com/p/chromium/issues/detail?id=31628
Earlier quoted context omitted.
Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.
You need three things: 1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication. 2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in). 3. Ability to monitor the SSL connection is it is transported across TCP. Would have been fun if they called this the CPE1704TKS a…
That one was not cracked one character at a time in series, portions in the middle were discovered sooner. But, yeah, would have been a more appropriate, cooler name.
Earlier quoted context omitted.
Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.
As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts. You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...
Doesn't look like this has anything to do with an exploit. It is because some older web servers who don't support TLS also don't support compression. See: http://code.google.com/p/chromium/issues/detail?id=31628
Earlier quoted context omitted.
You need three things: 1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication. 2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in). 3. Ability to monitor the SSL connection is it is transported across TCP. Would have been fun if they called this the CPE1704TKS a…
To expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.
Yes. See: http://security.stackexchange.com/a/19914
Very interesting, using differential analysis on the compression output is pretty clever.
Earlier quoted context omitted.
As I understand it, only 2 and 3 are needed. The (secret) cookies are the part that is determined by the SSL compression exploit, by trying subsequent parts. You're right that Hollywood "guess the password one character at a time" animation makes sense here. It also makes sense for timing based attacks. Ie, if checking "AB" against the password takes longer than "A", you know the second character is B...
What I meant was that the browser must have some cookies stored to send to the target, cookies that the attacker wants to discover.
1. Attacker controls some parts of plaintext
2. Attacker's content is mixed with content attacker wants to discover
3. Attacker can make repeated trials against the same plaintext (not against same ciphertext stream or key)
4. Defender compresses content on the fly
There are probably other cryptosystems that have this flaw, but it's less inherent to TLS than it is to the HTTPS security model.
Earlier quoted context omitted.
You need three things: 1. To know the format of cookies used for the web site you are targetting. Specifically, whatever cookie contains authentication. 2. The ability to injection a request to the target web server while someone is connected (such as with JavaScript, an XSS, or plug-in). 3. Ability to monitor the SSL connection is it is transported across TCP. Would have been fun if they called this the CPE1704TKS a…
To expand on your second point, if you have 3, then in many cases you also have the ability to intercept and modify non-encrypted traffic. Meaning, if the victim is using a secure web site and a non-secure site at the same time, the MITM can infiltrate the non-secure site and use it to generate requests to the secure site.
Yes. See: http://security.stackexchange.com/a/19914
Is my understanding correct that the attack described there requires all of 1. cookies associated with the target, 2. the ability to monitor the length of requests to the target, and 3. the ability to send requests to the target (e.g. JavaScript injection, malicious website)? I guess this is actually an instance where those Hollywood "guess the password one character at a time" animations would make sense.