Legacy MACs and Ciphers: Why?

[Aris Adamantiadis]

Hello,

I am not an openssh developer, but as someone who has worked with the
SSH protocol I have a few ideas on why it's not a so bad idea to keep
these ciphers.
First of all, as you mentioned, the list of the available ciphers can be
used by the client to choose from, so the client can decide what is
secure enough for it and select a cipher whose security is agreeing with
his view on security and performance.

An other important point is that the whole key exchange, including the
list of the ciphers, is part of the session key calculation. It means
that it is not possible to MiM a SSH connection and force the client to
use an outdated cipher. And so the security of the protocol does not
depend on the weakest cipher in the list (including macs).

About the "weak" mac algorithms: the purpose of the HMAC is to protect
the integrity of the content of an interactive session. It means that if
an attacker can break a specific HMAC to insert his own content, he
needs to do so in realtime, because SSH is a real time protocol. This
greatly mitigates all known vulnerabilities in MD5, which require at
least known plaintexts.

To finish, my opinion as a libssh developer is that it's pain when a ssh
server that is known to work perfectly with libssh at version X, stops
to work at version X+1 because a perfectly working but slightly insecure
version of cipher used in X is not available in X+1 anymore. While it's
true that it's important to support the most secure ciphers, having
enough time to do so is important. I'd like to add that some REQUIRED
ciphers are in the RFC for a reason (opensolaris breaking aes128-cbc
comes to my mind).

Kr,

Aris

Le 15/04/12 19:43, solo-openssl at goeswhere.com a écrit :
> Why are legacy MACs (like md5-96), and legacy Ciphers (anything in
> cbc-mode, arcfour*(?)) enabled by default?
> 
> My proposal would be to change the defaults for ssh_config and
> sshd_config to contain:
> 
>   MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1
>   Ciphers aes128-ctr,aes192-ctr,aes256-ctr
> 
> ...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
> broken algorithms?
> 
> 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.com,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),
> as above.
> 
> 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[1].
> 
> 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"[2] than any of
> the SHA- algorithms.  Maximum compatability, possibly.
> 
> Anything else?
> 
> 
> [1]: http://csrc.nist.gov/groups/ST/hash/policy.html
> [2]: http://www.cryptopp.com/benchmarks.html
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>