On 10/25/2013 03:23 PM, Mark E. Lee wrote:> Thanks for the response, what kind of problematic interactions would > occur (other than trying to compress seemingly random data)?e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where the attacker can inject pre-defined cleartext into the channel and can then observe length changes in the ciphertext to derive the other (non-injected) contents of the cleartext. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20131025/f819e912/attachment.bin>
I see. From reading that wikipedia article, I'm wondering what gets compressed when compression is enabled in openssh. Is it the ciphertext or the cleartext? Regards, Mark On Fri, 2013-10-25 at 15:47 -0400, Daniel Kahn Gillmor wrote:> On 10/25/2013 03:23 PM, Mark E. Lee wrote: > > Thanks for the response, what kind of problematic interactions would > > occur (other than trying to compress seemingly random data)? > > e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where the > attacker can inject pre-defined cleartext into the channel and can then > observe length changes in the ciphertext to derive the other > (non-injected) contents of the cleartext. > > --dkg > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev-- Mark E. Lee <mark at markelee.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20131025/d68c9660/attachment.bin>
Also nice to know that zlib at openssh.com enables the compression only after authentication, mitigating the known problems with compression and passwords. It is also very hard to do chosen-plaintext attacks on the client to server side (in opposite to HTTPS where that's trivial). And most passwords that are typed after authentications are entered character by character, making them fall under the padding length anyway. I think the compression vulnerabilities in CRIME are not appliable to SSH with delayed compression. Aris Le 25/10/13 21:47, Daniel Kahn Gillmor a ?crit :> On 10/25/2013 03:23 PM, Mark E. Lee wrote: >> Thanks for the response, what kind of problematic interactions >> would occur (other than trying to compress seemingly random >> data)? > > e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where > the attacker can inject pre-defined cleartext into the channel and > can then observe length changes in the ciphertext to derive the > other (non-injected) contents of the cleartext. > > --dkg > > > > _______________________________________________ openssh-unix-dev > mailing list openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >