When using compression on openssh (a la ssh -C ...), does this reduce entropy and make the tunnel traffic more vulnerable to cryptanalysis? Is compression an option I should disable server-side for this or any other reason?

I have a vague recollection of disabling compression being recommended for security reasons, but the rationale (if any) eludes me and my feeble Google queries.

  • 1
    Perhaps you're thinking of SSL and compression? security.stackexchange.com/questions/20216/… I don't know that this same attack applies to ssh. Jan 24, 2020 at 18:11
  • Ah, yes. I think you're correct. So is this technique only applicable to that crypto in TLS, or is it not a concern with SSH due to the difficulty of the attacker introducing attacker-controlled plaintext into the stream? Jan 24, 2020 at 18:19
  • I'm not familiar with the SSL attack to answer that question. That attack is old enough (2013?) that I'd have a suspicion that it might not be applicable to SSH since nobody seems to recommend turning off compression in ssh. Jan 24, 2020 at 18:30

1 Answer 1


Compression before encryption is a problem if the attacker can control parts of the transferred data and then use the detectable compression ratio (i.e. amount of transferred data vs. original data) to make conclusions about some of the traffic. This was in TLS used within BREACH and CRIME attacks to infer cookies and CSRF tokens. Making such attacks work requires the attacker to trigger repeated transmission of mostly the same data where the only difference is the attacker controlled part. This is feasible in several use cases of HTTPS.

While one might in theory use SSH in a similar scenario the common use case of SSH is not like this, i.e. the attacker has no control over parts of the input and can also not trigger sending nearly the same data again and again. In the common use cases of SSH compression before encryption is thus not a problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .