>I think SSH is the wrong layer to address this.
Sure,... as it was said, it's a general problem.
But I'd guess the more systematic compression is deployed (e.g. on a
protocol level) the easier it gets to exploit.
>People need to be
>wary of building application protocols that combine an authentication
>token (cookie, password) and known plaintext into frequent queries.
Well most of our people here using SSH aren't wary of very much - one
can basically be happy if they check fingerprints. ;-)
>The vast majority of SSH compression uses aren't concerned by this.
Sure, nevertheless, I've had a short glance at the source code:
Wouldn't it basically work to change in servconf.c:
{ "compression", sCompression, SSHCFG_GLOBAL },
to
{ "compression", sCompression, SSHCFG_ALL },
and when it was actually set in Match section, bail out with an error
when "yes" was used?
Since delayed compression happens only after authentication, this
should make it possible to use it with Match User.
Or do I miss something?
Sincerely,
Philippe
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
