stribika-rdonly
commented
9 years ago You are correct, SHA-1 collisions are not sufficient to break HMAC-SHA-1. I have no new attacks. Even HMAC-MD5 is safe. I did consider attacks on the hash function used as a KDF after the key exchange and in RSA signatures as well. To attack "SHA-1 as KDF" you need a preimage attack that works even if you only control part of the input. You can't really attack "SHA-1 in RSA" because of how the protocol works, you have to attack the entire construct: rsa_sign(sk, sha1(data_from_authenticated_server || sha2(shared_secret || attacker_controlled_data))).
However, I know it is somehow possible to break SSH so I recommend against using any algorithm that shows the slightest sign of weakness. They may not be a attacking the primitives but implementation flaws. So I recommend disabling stuff that's hard to implement. They may be exploiting weak RNGs, etc.
I chose paranoia over compatibility at every opportunity when I wrote this. The compatibility problems are listed here and I will add this information regarding ConnectBot and mention mobile clients in general on the main page when I get home. By the way, they are working on it.
I don't think these compatibility problems as serious as with TLS for example. SSH has important advantages in this area.
- No fallback to plaintext. Servers are not running telnet anymore and even if they were the fallback is not automatic.
- If you are a company, you typically control both ends of the connection. If you are using it at home, you also control both ends. There are of course exceptions, such as services offered publicly, like github.
- Users are skilled enough to upgrade or reconfigure their clients. They are expected to manage a server after all. This is not necessarily true for tunneling.
Large scale server upgrades and even config changes are painful though. If you have tens of thousands of servers, you have to make the change process very resilient to low memory, low diskspace, out of PIDs, power loss, race conditions, etc.
What's wrong with 32 byte digest length?
rhyven
mgkuhn
markhahn
jauderho
This document has encouraged one of our system administrators to disable any use of SHA-1 in a major SSH server at our site. This has caused compatibility problems, in particular for users of various mobile phone and tablet SSH clients that do not yet support SHA-2.
It would be nice if you could add two things:
a) List which widely used SSH clients are or are not yet compatible with your configuration, to better inform the paranoia-versus-usability trade-off involved.
b) A more detailed discussion of what practical security is actually gained (or not) by disabling SHA-1.
For a) I can note the following:
The Android SSH client ConnectBot version 1.7.1 (the latest version released on Google Play at the time of writing this) only supports the following algorithms:
Therefore, any SHA-2-only configuration will not work with it yet.
Likewise, the iOS ssh client "iSSH - SSH / VNC Console, v5.3.2" by Zinger-Soft appears not compatible.
For b), it would be useful to note the following, to put worries about SHA-1 security into perspective:
The property of SHA-1 that is most suspected is its collision resistance, that is the cost for an adversary to find a pair of messages X != Y such that H(X) = H(Y). Collision resistance is of crucial importance in certificate applications, because lack of collision resistance allows an adversary to present one object X to a certification authority and another object Y to the verifier of the resulting certificate or signature. The lack of collision resistance in MD5 was reportedly abused to sign components of the Flame malware. While similar chosen-prefix collisions have not yet been demonstrated for SHA-1, this is one of several events that has caused a drive to phase out the use of SHA-1 in certificates.
However, if you do not use SSH with certificates, then what risks are there from the ~2^60 collision attacks that have been proposed for SHA-1? Where SHA-1 is used inside the HMAC construction, none of the proposed attacks are applicable, because the attacker knows nothing about the internal state or the output of the inner SHA-1 invocation in HMAC. The HMAC construct provides powerful safeguards around the hash function, by putting it into an unknown state and finally passing its output through a pseudo-random function. Another application of SHA-1 in SSH is as part of the digital signatures that authenticate the exchanged Diffie-Hellman parameters. Again, collision-resistance is not essential here, because a collision can only be abused in applications where a digital signature is verified by at least two different parties (which could be shown different X and Y). Without certificates, the digital signatures generated in the SSH protocol are only ever verified once, by the recipient, and therefore there is nothing useful an adversary could do with a collision they have found. A lack of second-preimage resistance would obviously be of much more concern, but the only proposed attack that I am aware of is the one by Kelsey and Scheier, which still costs 2^106 steps, and which can therefore hardly be described as practical.
No doubt, it is very nice to have SHA-2 (and SHA-3!) widely implemented as fall-back options. But I can not yet see anything in the current research literature that would justify breaking compatibility with widely used SSH clients by disabling SHA-1 today, considering that (without certificates) SSH does not rely on the collision resistance of this secure hash function.
Remember that if you disable a security mechanism, some of your users might chose to circumvent this measure by falling back to some even less secure techniques. In particular, HMAC-SHA-1 is very likely to be far more secure than not using SSH at all, if that is the alternative.
Perhaps the document could be structured such that disabling SHA-1 is left as a step for the future, once it has been more widely implemented on mobile OS SSH clients? After all, hmac-sha2-256 was only defined in July 2012 and has a ridiculously-long digest length of 32 bytes.