can compression be safely used with SSH?

[Philippe Cerfon]

Hello.

At work we collect logs (via ssh) from all kinds of hosts on one
central node which has no connection to the internet and is tried to
kept secure.
The idea is, as you can imagine, that in case of a compromise we'd
have at least all the logs up to the break without any forgeries.
The logging is done continuously and compression is used.

Now the following is not really that much relevant for the our
scenario, where all nodes are in one intranet, but I was speculating
with a colleague of mine, whether this (and SSH in general) could be
abused for CRIME/BREACH like attacks.


Now I'm aware that at least OpenSSH uses the delayed compression so
it's not so easy as with webservers, but when you look at how we use
it - it should be quite simple for an attacker to inject some chosen
plain texts in our logs (e.g. logs from a webserver).


As war as I understood, the idea of CRIME and friends was that one
knows the parts of the plain text, sees how the ciphertext changes and
can then use the change of length in cryptoanalysis.

So what exactly does that mean? Can it be used to get more knowledge
on the used session keys?
Or can it be used to possibly decrypt that block of data which
contained the plaintext?

Of course in SSH it wouldn't be that easy, where one might have something like:
GET /fobar?password=secret&chosenPlainText=gotcha

So there is not such direct way to extract a secret as it was made
possible in an attack like CRIME, but yet it may theoretically be
possible to get out something useful, or wouldn't it?
So I could be stupid and have a log format in Apache httpd which is like:
<date> myrootpassword=iamdumb <request URI>

Now in the above scenario and attacker that could eavesdrop our log
collector's connections, could also make arbitrary requests to our
company's webserver, thereby change places chosen plaintexts <request
URI> and by the compression deduce the password.


As I've said, the whole thing is probably no real world thread. I'm
rather wondering whether SSH would be in principle vulnerable too


I found http://thread.gmane.org/gmane.network.openssh.devel/20016 in
the archives, which implies that the delayed compression would make it
secure.
a) So how would that prevent the basic idea of the attack as outlined above?
b) Why would the non-delayed compression be insecure? Okay there might
be a valuable secret involved (e.g. the passphrase) which is then
compressed, but an attacker can likely not inject and chosen plain
texts at that step of protocol negotiation between a valid client and
the server?
And what would it help him, if the attacker on himself makes gazillion
connections requests, altering e.g. the user- or algo names? Nothing
valuable should have been sent to an unauthenticated client by the
server at that stage.


Regards,
Philippe.