Mailing List Archive

Legacy MACs and Ciphers: Why?
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@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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Legacy MACs and Ciphers: Why? [ In reply to ]
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@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@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev