solo-openssl at goeswhere
Apr 15, 2012, 10:43 AM
Why are legacy MACs (like md5-96), and legacy Ciphers (anything in
Legacy MACs and Ciphers: Why?
cbc-mode, arcfour*(?)) enabled by default?
My proposal would be to change the defaults for ssh_config and
sshd_config to contain:
...removing md5, truncated versions of sha1, umac64 (for
which I can find barely any review), any cipher in cbc mode
and other non-mainstream algorithms.
Additionally, why does ssh_config prefer hmac-md5 over less
Even if the above reduction of attack surface were not to happen,
ssh_config could be changed such that the client prefers
"more secure" algorithms if practical; i.e. change the default to:
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-ripemd160,umac-64 [at] openssh,hmac-md5,hmac-sha1-96,hmac-sha2-512-96,hmac-sha2-256-96,hmac-md5-96
"Ciphers" already "prefers" aes128-ctr, which seems reasonable.
A quick review of available ssh clients [.various free/shareware
Windows clients (PuTTY derivatives (WinSCP), AbsoluteTelnet),
dropbear, ConnectBot, Java libraries, ..], indicates universal
support for hmac-sha1. hmac-sha256 and hmac-sha512, not so much.
Everything I tested, however, was happy to ignore hmac-sha2-256
at the start of the specification list (as expected by the spec),
Incompatabilities of servers seem less important as the user may
reconfigure the client. I am not aware of any widely deployed
non-OpenSSH ssh servers to test against?
I am aware that there are no attacks against MD5 with HMAC
yet [RFC 6151], nor any widely reported practical attacks against
cbc mode. I am aware that even SHA-1's use in as part of an HMAC
construction has not been deprecated.
I feel that the migration away from otherwise deprecated
technologies is the right way to go? If not, I'm interested
in what decisions have been made with respect to these lists.
Speed may be a consideration; MD5 is "faster" than any of
the SHA- algorithms. Maximum compatability, possibly.
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot