21–30 of 137 posts
Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".
I think it's time for me to write a blog post entitled "on the provable security of spiped". Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".
Yes. See: http://security.stackexchange.com/a/19914
Compression: Specifies whether compression is allowed, or delayed until the user has authenticated successfully. The argument must be "yes", "delayed", or "no". The default is "delayed".
I don't know why they chose "delayed" as default, but this seems to prevent this attack.
I think it's time for me to write a blog post entitled "on the provable security of spiped". Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".
What, compressing before encrypting?
Earlier quoted context omitted.
What, compressing before encrypting?
Yes. There's absolutely zero excuse for including compression as part of a cryptographic protocol.
It's easy for me to believe that you've internalized "minimize data-dependent branches in crypto code" and thus wouldn't have designed a compressed encrypted transport.
It is very hard for me to believe that you would have spotted this flaw immediately had anyone pointed out to you that TLS supported compression.
There is well-regarded (though not by me) crypto advice recommending that people compress before encrypting, to destroy structure in the plaintext.
Earlier quoted context omitted.
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.
I think you're correct here but how would you manipulate the cookies being sent when sending XSS requests from a different domain?
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…
I think it's time for me to write a blog post entitled "on the provable security of spiped". Seriously, we know how to build secure cryptographic protocols. Unfortunately, step #1 is "don't try to be backwards compatible with the horribly broken things people were doing in the 1990s".
What, compressing before encrypting?
(Reason: because encrypted data is [should be] indistinguishable from random data, and random data does not compress)