Recently I have been working on purging DSA from my computer systems. The problem with DSA and ECDSA is that they fail catastrophically with when nonces are accidentally reused, or if the randomly generated nonces are biased. At about the same time, I was pleased to discover an article on securing SSH. It gives further advice in setting up SSH and I have proceeded to apply most of the recommendation listed there.
For key exchange algorithms, the article suggests using curve25519-sha256 and falling back to diffie-hellman-group-exchange-sha256 for compatibility purposes if you must.
The diffie-hellman-group-exchange-sha256 protocol allows the client and server to negotiate a prime field to perform the key exchange in.
In order to avoid using the smaller prime fields, the article suggests deleting prime numbers less than 2000 bits in size from /etc/ssh/moduli.
The problem with this advice is that only the SSH server reads /etc/ssh/moduli; touching this file does nothing to secure your SSH client from using small prime fields during key negotiation.
Securing the client is the important use case for diffie-hellman-group-exchange-sha256, because if you can control the server, then it means you will probably use curve25519-sha256 instead.
However, the protocol for diffie-hellman-group-exchange-sha256 does allow the client to negotiate the field side.
The problem is that this ability is not exposed for configuration in SSH.
To address this, I created a patch for OpenSSH that raises the minimum field size allowed for the diffie-hellman-group-exchange-sha256 key exchange for both the client and server.
This means you do not need to edit the /etc/ssh/moduli file to increase the minimum field size for the server, but it will not hurt to do so either.
If you are running NixOS you can download the patch and add it to your /etc/nixos/configuration.nix file with the following attribute.
nixpkgs.config.packageOverrides = oldpkgs: {
openssh = pkgs.lib.overrideDerivation oldpkgs.openssh (oldAttrs: {
patches = oldAttrs.patches ++ [ ./openssh-dh-grp-min.patch ];
});
};
As an aside, I noticed that this key exchange protocol has a design flaw in it.
The hash signed by the server is the hash of V_C || V_S || I_C || I_S || K_S || min || n || max || p || g || e || f || K.
The details of what those variables stand for is not important.
What is important is that there is a older format of the protocol that is supported for backwards compatibility where the hash signed by the server is the hash of V_C || V_S || I_C || I_S || K_S || n || p || g || e || f || K.
In this older protocol, the client only requests a field size without specifying the minimum and maximum allowed bounds.
This is why the variables min and max are do not appear in the hash of the older protocol.
A short header is sent by the client to determine which of these two versions of this protocol it is using.
The problem is that this header is not part of the hashed data. This little crack has potential to be an exploit. A MITM attacker could replace the header the client sends with the old protocol header, and then try to manipulate the remaining communication between the client and server so that both the client and server hash the same serialized byte string allowing the server to appear to be authenticated to the client, but where the client and server are interpreting that serialized byte string in two different ways. In particular the MITM wants the client to not be doing computation modulo some safe prime, but instead do modular arithmetic over a different ring entirely.
Fortunately this particular little crack does not appear to be wide enough to exploit. The incidental properties of the serialization format do not allow a successful manipulation, at least not in practical SSH configurations.
When one is signing a serialized blob of data, it is important that the data can be unambiguously parsed using only the contents of that data.
This principle is violated here because one cannot decide if one will parse min and max without knowing the header, which is not part of the serialized blob of data.
The reason this failure can so easily creep into the protocol is that neither the client nor the server actually have to parse that blob of data.
They both serialize the data and then create or verify the signature, but parsing is never done. Therefore, parsing is never implemented.
Since parsing is not implemented, it is easy to miss that the data serialization format is ambigous.