[Bug 2322] New: please let the server enable/disable delayed compression on a per user basis
bugzilla-daemon at mindrot.org
bugzilla-daemon at mindrot.org
Mon Dec 1 14:23:52 EST 2014
https://bugzilla.mindrot.org/show_bug.cgi?id=2322
Bug ID: 2322
Summary: please let the server enable/disable delayed
compression on a per user basis
Product: Portable OpenSSH
Version: 3.7p1
Hardware: All
OS: All
Status: NEW
Severity: enhancement
Priority: P5
Component: sshd
Assignee: unassigned-bugs at mindrot.org
Reporter: philcerf at gmail.com
Hi.
This is basically from
https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-November/033176.html
.
1) In encryption, compression may generally be abused as an oracle for
side-channel attack, when the attacker can inject chosen-plaintext
(e.g. as in CRIME and BREACH attacks).
While this is far less likely for SSH as in CRIME and BREACH it's not
really impossible to happen (see the above mail thread for example
scenarios like log files that are transferred via SSH).
The SSH client side can protect against this, simply by disabling
encryption.
The SSH server side may want to only allow certain users to use
SSH-protocol-level compression. E.g. users which are only used for
automated systems where it's known that no chosen plain text can be
injected,... or human users which have been educated about that
principal problem.
Of course, even when SSH-level compression is disallowed, users could
still do any other manual compression, which would be vulnerable to the
same problem - but better protect against something than nothing.
2) Even though gzip is a rather fast compression algorithm (at least
compared to some others), it may be desirable for a sysadmin to allow
only certain users to enable encryption (especially since the user
could choose high compression levels) in order to prevent overloading
the system.
For these two motivations, it would be nice if one could control on the
SSH server side, whether a user is allowed to use compression or not,
ideally via the Match block, e.g.
#global setting:
Compression no
#per user settings:
Match User foo bar
Compression delayed
As Damien suggested in the thread above - a clean solution would be,
that if such configuration is given, the server enforces a
key-renegotiation immediately after the handshake with the "new"
compression algos.
Regards,
Philippe
--
You are receiving this mail because:
You are watching the assignee of the bug.
More information about the openssh-bugs
mailing list