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. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
