Mailing List Archive

SHA-1 practical recommendations?
The release notes currently:
- explain the flaws with SHA-1,
- alert people to the evolution of UpdateHostKeys (default since 8.5),
- a command to check if a server uses ssh-rsa
- suggest upgrading OpenSSH

There are a few issues:

What does "default" mean, "yes", or "ask"? I think it is "yes" but it
could be helpful to clarify that in both release notes and the man page.

Does the command for checking ssh-rsa distinguish between SHA-1
(insecure) and SHA-2?

Many people won't upgrade SSH, they will probably just wait either (a)
they upgrade their whole distribution or (b) their distribution provides
a security update of the package with SHA1 disabled at compile time

Some pages have appeared about tweaking /etc/ssh/sshd_config on every
host, adding the MACs parameter and specifying the secure MACs. The
OpenSSH release notes don't mention this.

Are there any more specific documents available?

If yes, could you link to them from the release notes and man page?

If no, is there a good place to maintain a FAQ about this issue?

Some of the questions that come to mind from the perspective of somebody
who uses ssh but doesn't look under the hood:

- brief example of how an attack may work in practice

- are hash values cached anywhere in the client (known_hosts), server
(sshd_host*) or only generated on the fly and used on the wire?

- some sites suggest setting MACs in sshd_config, listing only the
secure values, is there a compelling reason to do this proactively? It
appears more important to set this on the client side

- is there a convenient shortcut to enable only strong hashes in
ssh(d)_config MACs without itemizing them?

- instead of waiting for new versions of the packages to remove SHA-1,
should security-conscious users consider setting MACs in every
sshd_config and ssh_config on their site?

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On 10/03/2021 15:55, Daniel Pocock wrote:
> Does the command for checking ssh-rsa distinguish between SHA-1
> (insecure) and SHA-2?

The older ssh-rsa algorithm *only* uses SHA-1. The SHA-2 versions are
rsa-sha2-256 and rsa-sha2-512. If connecting to a server succeeds when
the former is excluded, the server supports SHA-2. If it does not, it
only supports SHA-1.

This also has nothing to do with the MACs setting; HMAC-SHA1 is still
secure (as is HMAC-MD5).
Re: SHA-1 practical recommendations? [ In reply to ]
On 10/03/2021 20:05, Aaron Jones wrote:
> On 10/03/2021 15:55, Daniel Pocock wrote:
>> Does the command for checking ssh-rsa distinguish between SHA-1
>> (insecure) and SHA-2?
>
> The older ssh-rsa algorithm *only* uses SHA-1. The SHA-2 versions are
> rsa-sha2-256 and rsa-sha2-512. If connecting to a server succeeds when
> the former is excluded, the server supports SHA-2. If it does not, it
> only supports SHA-1.
>
> This also has nothing to do with the MACs setting; HMAC-SHA1 is still
> secure (as is HMAC-MD5).

Thanks for the fast reply

This is one of the search results for hardening that suggests tweaking
MACs, this is the reason I wanted to seek clarification:

https://access.redhat.com/discussions/3121481

What about KexAlgorithms - should people change this either on client,
server or both to remove entries like
diffie-hellman-group-exchange-sha1, and diffie-hellman-group14-sha1 ?

Is there any SHA1 value cached in known_hosts or does that only contain
full public keys?

Regards,

Daniel
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On 10/03/2021 19:16, Daniel Pocock wrote:
> Thanks for the fast reply
>
> This is one of the search results for hardening that suggests tweaking
> MACs, this is the reason I wanted to seek clarification:
>
> https://access.redhat.com/discussions/3121481
>
> What about KexAlgorithms - should people change this either on client,
> server or both to remove entries like
> diffie-hellman-group-exchange-sha1, and diffie-hellman-group14-sha1 ?

Don't get me wrong; disabling old algorithms that you won't be using is
nearly always a Good Thing. It also keeps out a lot of the SSH
dictionary attack bots (but you should still not be using passwords
anyway). I, for example, run all of my servers with:

Ciphers chacha20-poly1305@openssh.com
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com
KExAlgorithms curve25519-sha256
MACs umac-128-etm@openssh.com
PubkeyAcceptedAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
RekeyLimit 128M 1h

You will have to evaluate whether this is a suitable choice for your
deployments, and test them, as is the case with any other piece of software.

> Is there any SHA1 value cached in known_hosts or does that only
> contain full public keys?

The known_hosts file only contains keys. There's a difference between
*key type* and *signature algorithm*. The "ssh-rsa" *key type* can still
be used; i.e. you can still run an SSH server with only an RSA host key,
as long as the server supports a SHA-2 *signature algorithm*. The test
command provided in the 8.5 release notes disables the ssh-rsa
*signature algorithm*.
Re: SHA-1 practical recommendations? [ In reply to ]
Daniel Pocock <daniel@pocock.pro> writes:

> What about KexAlgorithms - should people change this either on client,
> server or both to remove entries like
> diffie-hellman-group-exchange-sha1, and diffie-hellman-group14-sha1 ?

You may find interest in the IETF draft

https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

Any KeX with *sha1* in the name should be avoided or put last in the
list to be negotiated.

> Is there any SHA1 value cached in known_hosts or does that only
> contain full public keys?

The SSH host keys are just the public keys. The hash is determined by
the negotiation.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
As others have mentioned, there is guidance about this in
draft-ietf-curdle-ssh-kex-sha2:

https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/

In summary, of these SHA-1 KexAlgorithms:

* diffie-hellman-group1-sha1
* diffie-hellman-group14-sha1
* diffie-hellman-group-exchange-sha1

and these SHA-1 GSSAPIKexAlgorithms:

* gss-gex-sha1-
* gss-group1-sha1-
* gss-group14-sha1-

…if it is necessary to enable one of them for backward compatibility
with clients/servers that support only SHA-1 algorithms, then this is
the only one that should be enabled:

* diffie-hellman-group14-sha1 (for KexAlgorithms)
* gss-group14-sha1- (for GSSAPIKexAlgorithms)

…because of the three, only group14-sha1 is using a 2048-bit MODP
group. So if one must be enabled, it is the least-bad one to enable.

This reasoning was explained in a previous version of the kex draft:

https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-11.html

Unfortunately, the explanation in the current version of the draft is
arguably less clear.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
James Ralston <ralston@pobox.com> writes:

> As others have mentioned, there is guidance about this in
> draft-ietf-curdle-ssh-kex-sha2:
>
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
> In summary, of these SHA-1 KexAlgorithms:
>
> * diffie-hellman-group1-sha1
> * diffie-hellman-group14-sha1
> * diffie-hellman-group-exchange-sha1
>
> and these SHA-1 GSSAPIKexAlgorithms:
>
> * gss-gex-sha1-
> * gss-group1-sha1-
> * gss-group14-sha1-
>
> …if it is necessary to enable one of them for backward compatibility
> with clients/servers that support only SHA-1 algorithms, then this is
> the only one that should be enabled:
>
> * diffie-hellman-group14-sha1 (for KexAlgorithms)
> * gss-group14-sha1- (for GSSAPIKexAlgorithms)
>
> …because of the three, only group14-sha1 is using a 2048-bit MODP
> group. So if one must be enabled, it is the least-bad one to enable.
>
> This reasoning was explained in a previous version of the kex draft:
>
> https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-11.html
>
> Unfortunately, the explanation in the current version of the draft is
> arguably less clear.

Yup, a reviewer did not like my explaination and asked me to remove it.

group14 provides for 112 bits of security strength.

sha1 provides a nominal 80 bits of security strength, but due to the
current compromises, it may be as weak as only 64 bits of security
strength.

So,the *group14-sha1* has security strength MIN(112, 64) == ~64 bits of
security strength.

When trying to use this with 3des-cbc which has a nominal 112 bits of
security, but weaknesses associated with a small block size, the
security strength may be less secure than 112 bits.

That said, the shared key generated by the key exchange will not really
have enough security strength for most users.

Realistically, to provide for 128 bits of security strength
for symmetric Ciphers:

aes128-ctr,
aes128-cbc,
aes128-gcm@openssh.com
AEAD_AES_128_GCM

which all have symmetric keys of ~128 bits of security strength, one may
use any of these key exchanges:

curve25519-sha256
curve448-sha512
diffie-hellman-group-exchange-sha256
diffie-hellman-group15-sha512
diffie-hellman-group16-sha512
diffie-hellman-group17-sha512
diffie-hellman-group18-sha512
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
gss-curve25519-sha256-*
gss-curve448-sha512-*
gss-group15-sha512-*
gss-group16-sha512-*
gss-group17-sha512-*
gss-group18-sha512-*

security strength and work fine.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Wed, 10 Mar 2021, James Ralston wrote:

> As others have mentioned, there is guidance about this in
> draft-ietf-curdle-ssh-kex-sha2:
>
> https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
>
> In summary, of these SHA-1 KexAlgorithms:
>
> * diffie-hellman-group1-sha1
> * diffie-hellman-group14-sha1
> * diffie-hellman-group-exchange-sha1

(none of these are enabled by default in OpenSSH)

> and these SHA-1 GSSAPIKexAlgorithms:
>
> * gss-gex-sha1-
> * gss-group1-sha1-
> * gss-group14-sha1-

(these are added by a popular third-party patch to OpenSSH)

> …if it is necessary to enable one of them for backward compatibility
> with clients/servers that support only SHA-1 algorithms, then this is
> the only one that should be enabled:
>
> * diffie-hellman-group14-sha1 (for KexAlgorithms)
> * gss-group14-sha1- (for GSSAPIKexAlgorithms)

Disagree. diffie-hellman-group-exchange-sha1 will use a bigger/better
MODP group than group14. If I had to enable one then that would be it.

As an aside, I don't think there is honestly any concern about using
SHA1 in the key exchange hash - collisions there don't matter as the
hash is used solely as a PRF and the input to hashing is not under
either party's sole control.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
Damien Miller <djm@mindrot.org> writes:

> On Wed, 10 Mar 2021, James Ralston wrote:
>
> > As others have mentioned, there is guidance about this in
> > draft-ietf-curdle-ssh-kex-sha2:
> >
> > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
> >
> > In summary, of these SHA-1 KexAlgorithms:
> >
> > * diffie-hellman-group1-sha1
> > * diffie-hellman-group14-sha1
> > * diffie-hellman-group-exchange-sha1
>
> (none of these are enabled by default in OpenSSH)

I agree.

> > and these SHA-1 GSSAPIKexAlgorithms:
> >
> > * gss-gex-sha1-
> > * gss-group1-sha1-
> > * gss-group14-sha1-
>
> (these are added by a popular third-party patch to OpenSSH)

Yup.

> > …if it is necessary to enable one of them for backward compatibility
> > with clients/servers that support only SHA-1 algorithms, then this is
> > the only one that should be enabled:
> >
> > * diffie-hellman-group14-sha1 (for KexAlgorithms)
> > * gss-group14-sha1- (for GSSAPIKexAlgorithms)
>
> Disagree. diffie-hellman-group-exchange-sha1 will use a bigger/better
> MODP group than group14. If I had to enable one then that would be it.

It is hard to know what a particular server is going to put into that
file. It may or may not be the moduli file shipped with OpenSSH. The
OpenSSH 8.5p1 release seems to provide many 2048-bit MODP groups.

It can also be hard to know if a third-party is injecting a PseudoPrime
there... I have an idea for 'fixing' that, but I have not written an
IETF Draft to do anything about it, nor have I provided patches to
anyone for it.

> As an aside, I don't think there is honestly any concern about using
> SHA1 in the key exchange hash - collisions there don't matter as the
> hash is used solely as a PRF and the input to hashing is not under
> either party's sole control.

Yup, that is a completely rational point of view.

There are those out there with IoT devices that need/want to continue
using diffie-hellman-group1-sha1 key exchanges.

There are those out there (mostly banks and governments) who are more
paranoid about SHA-1 being broken "very soon" as well as those who are
pushing for calculations on security level (bits of security) being
maintained throughout the calculations.

I started out wanting to get an RFC to disallow
diffie-hellman-group1-sha1 and rsa1024-sha1 key exchanges and the
requirements for my draft kept growing until now it is almost trying to
be a best practices document.

Removing all of the *sha1* hashing in key exchanges is desired by some
and transitioning from a MUST (for the original group1-sha1 and
group14-sha1 kex list) implement to SHOULD NOT or MUST NOT implement for
others.

There are those who feel that FFC should be thrown away in favor of ECC
key exchanges and those who file that PQC is coming soon and will be
able to factor ECC faster than FCC.

I am presently trying to make the argument that *sha1* in the key
exchange is not as good as *sha256* or *sha512* or (for ecdh-nistp384)
sha384.

In my opinion, if you need a *sha1* kex in your list, then put it at the
end of the negotiation list. In the best of all possible worlds, they
should not really be needed. However, we are not there given an
installed base of SSH implementations exist for some devices that still
want to use group1-sha1 only.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Wed, 10 Mar 2021, Mark D. Baushke wrote:

> Damien Miller <djm@mindrot.org> writes:
>
> > On Wed, 10 Mar 2021, James Ralston wrote:
> >
> > > As others have mentioned, there is guidance about this in
> > > draft-ietf-curdle-ssh-kex-sha2:
> > >
> > > https://datatracker.ietf.org/doc/draft-ietf-curdle-ssh-kex-sha2/
> > >
> > > In summary, of these SHA-1 KexAlgorithms:
> > >
> > > * diffie-hellman-group1-sha1
> > > * diffie-hellman-group14-sha1
> > > * diffie-hellman-group-exchange-sha1
> >
> > (none of these are enabled by default in OpenSSH)
>
> I agree.
>
> > > and these SHA-1 GSSAPIKexAlgorithms:
> > >
> > > * gss-gex-sha1-
> > > * gss-group1-sha1-
> > > * gss-group14-sha1-
> >
> > (these are added by a popular third-party patch to OpenSSH)
>
> Yup.
>
> > > …if it is necessary to enable one of them for backward compatibility
> > > with clients/servers that support only SHA-1 algorithms, then this is
> > > the only one that should be enabled:
> > >
> > > * diffie-hellman-group14-sha1 (for KexAlgorithms)
> > > * gss-group14-sha1- (for GSSAPIKexAlgorithms)
> >
> > Disagree. diffie-hellman-group-exchange-sha1 will use a bigger/better
> > MODP group than group14. If I had to enable one then that would be it.
>
> It is hard to know what a particular server is going to put into that
> file. It may or may not be the moduli file shipped with OpenSSH. The
> OpenSSH 8.5p1 release seems to provide many 2048-bit MODP groups.
>
> It can also be hard to know if a third-party is injecting a PseudoPrime
> there... I have an idea for 'fixing' that, but I have not written an
> IETF Draft to do anything about it, nor have I provided patches to
> anyone for it.

I'm not sure whether that is a desirable thing to exploit to begin
with - it's detectable (even off-path!) and a lot of work for an evil
server to go through when they could just silently leak the derived
key...

> > As an aside, I don't think there is honestly any concern about using
> > SHA1 in the key exchange hash - collisions there don't matter as the
> > hash is used solely as a PRF and the input to hashing is not under
> > either party's sole control.
>
> Yup, that is a completely rational point of view.
>
> There are those out there with IoT devices that need/want to continue
> using diffie-hellman-group1-sha1 key exchanges.

Yikes - ECC is faster and offers a far better security margin.
group1 is probably going to be one of the next things we remove.

> There are those out there (mostly banks and governments) who are more
> paranoid about SHA-1 being broken "very soon" as well as those who are
> pushing for calculations on security level (bits of security) being
> maintained throughout the calculations.

I'm not sure what that means in the case of a PRF - no modern hash has
(not even MD5) been broken so badly that it fails to function as a PRF.

Unless you mean that the blocksize of the hash has to match the
expected security level of the key exchange and/or that of the
subsequent symmetric cipher. I'm not sure whether that is well-
justified either - an interating hash-based KDF can have as many
bits of output as you want, and SSH is almost always going to demand
more bits from the KDF than the underlying hash block size (because
2x keys, 2x IVs, etc).

> I started out wanting to get an RFC to disallow
> diffie-hellman-group1-sha1 and rsa1024-sha1 key exchanges and the
> requirements for my draft kept growing until now it is almost trying to
> be a best practices document.
>
> Removing all of the *sha1* hashing in key exchanges is desired by some
> and transitioning from a MUST (for the original group1-sha1 and
> group14-sha1 kex list) implement to SHOULD NOT or MUST NOT implement for
> others.

I think the strongest argument for unconditionally deprcating SHA-1
everywhere is that doing so hastens the day when we can simply remove
it. It's not great to leave partially-broken algorithms laying around
and simpler for everyone just to get rid of them as fast as
compatibility allows.

> There are those who feel that FFC should be thrown away in favor of ECC
> key exchanges and those who file that PQC is coming soon and will be
> able to factor ECC faster than FCC.

I'm pretty much one of them :) I'm skeptical whether useful QCs will be
a thing in my lifetime, but the probability is far enough above zero that
it makes sense to use PQC if the costs aren't too high.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Wed, Mar 10, 2021 at 7:43 PM Damien Miller <djm@mindrot.org> wrote:

> On Wed, 10 Mar 2021, James Ralston wrote:
>
> > …if it is necessary to enable one of them for backward
> > compatibility with clients/servers that support only SHA-1
> > algorithms, then this is the only one that should be enabled:
> >
> > * diffie-hellman-group14-sha1 (for KexAlgorithms)
> > * gss-group14-sha1- (for GSSAPIKexAlgorithms)
>
> Disagree. diffie-hellman-group-exchange-sha1 will use a
> bigger/better MODP group than group14. If I had to enable one then
> that would be it.

Is this guaranteed to be true even if /etc/ssh/moduli contains small
primes (e.g. 1023 bits)?

For example, RHEL7 ships OpenSSH 7.4, which contains:

$ head -7 /etc/ssh/moduli | cut -c1-70
# $OpenBSD: moduli,v 1.18 2016/08/11 01:42:11 dtucker Exp $
# Time Type Tests Tries Size Generator Modulus
20150520233853 2 6 100 1023 5 DB662973FB21C0B7BF21AB46AFD3E2002AE70C92
20150520233854 2 6 100 1023 5 DB662973FB21C0B7BF21AB46AFD3E2002AE70C92
20150520233854 2 6 100 1023 2 DB662973FB21C0B7BF21AB46AFD3E2002AE70C92
20150520233855 2 6 100 1023 5 DB662973FB21C0B7BF21AB46AFD3E2002AE70C92
20150520233856 2 6 100 1023 2 DB662973FB21C0B7BF21AB46AFD3E2002AE70C92

If we enable diffie-hellman-group-exchange-sha1, our InfoSec guys tell
us that our RHEL7 hosts all hit on:

https://www.tenable.com/plugins/nessus/86328

In contrast, group14 guarantees that the MODP group won’t be less than
2048.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Thu, 11 Mar 2021, James Ralston wrote:

> On Wed, Mar 10, 2021 at 7:43 PM Damien Miller <djm@mindrot.org> wrote:
>
> > On Wed, 10 Mar 2021, James Ralston wrote:
> >
> > > …if it is necessary to enable one of them for backward
> > > compatibility with clients/servers that support only SHA-1
> > > algorithms, then this is the only one that should be enabled:
> > >
> > > * diffie-hellman-group14-sha1 (for KexAlgorithms)
> > > * gss-group14-sha1- (for GSSAPIKexAlgorithms)
> >
> > Disagree. diffie-hellman-group-exchange-sha1 will use a
> > bigger/better MODP group than group14. If I had to enable one then
> > that would be it.
>
> Is this guaranteed to be true even if /etc/ssh/moduli contains small
> primes (e.g. 1023 bits)?

Yes, see dh_estimate() in dh.c - it will never select a <2048 bit
group and will usually select one considerably larger,

If /etc/moduli is missing then dh_new_group_fallback() will use either a
2k or 4k group.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Fri, 12 Mar 2021, Damien Miller wrote:

> > Is this guaranteed to be true even if /etc/ssh/moduli contains small
> > primes (e.g. 1023 bits)?
>
> Yes, see dh_estimate() in dh.c - it will never select a <2048 bit
> group and will usually select one considerably larger,
>
> If /etc/moduli is missing then dh_new_group_fallback() will use either a
> 2k or 4k group.

or an 8k group
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Thu, Mar 11, 2021 at 5:01 PM Damien Miller <djm@mindrot.org> wrote:

> On Thu, 11 Mar 2021, James Ralston wrote:
>
> > On Wed, Mar 10, 2021 at 7:43 PM Damien Miller <djm@mindrot.org> wrote:
> >
> > > diffie-hellman-group-exchange-sha1 will use a bigger/better MODP
> > > group than group14. If I had to enable one then that would be
> > > it.
> >
> > Is this guaranteed to be true even if /etc/ssh/moduli contains
> > small primes (e.g. 1023 bits)?
>
> Yes, see dh_estimate() in dh.c - it will never select a <2048 bit
> group and will usually select one considerably larger,
>
> If /etc/moduli is missing then dh_new_group_fallback() will use
> either a 2k or 4k group.

Who is determining this, though? The client or the server?

This exchange:

debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 4092/8192
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY

…suggests that the client tells the server its minimum, desired, and
maximum group size, and the server picks a group accordingly.

But what happens if a random ssh client (not OpenSSH) sends this?

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<1024) sent

Will OpenSSH server honor this and pick a 1024-bit group?

The Nessus hits against our RHEL7 hosts that have group-exchange
enabled suggests that OpenSSH server will honor this request.

The documentation for the Nessus plugin that tests this points to this
page:

https://stribika.github.io/2015/01/04/secure-secure-shell.html

…which suggests that removing all groups with size <2047 from
/etc/ssh/moduli will prevent OpenSSH server from picking any group
with less than 2048 bits. (Which, at that point, will break the
client?)

In summary, I think what this boils down to is that for OpenSSH
client, if SHA-1 key exchange algorithms must be enable for backward
compatibility, then the preferred list/ordering should be:

* diffie-hellman-group-exchange-sha1
* diffie-hellman-group14-sha1

This is true because OpenSSH client is well-behaved when it comes to
picking the size of the group for group-exchange, such that it will
never be smaller than group14 (2048), and will almost always be
larger.

But: for OpenSSH server, it is not safe to enable either of:

* diffie-hellman-group-exchange-sha1
* diffie-hellman-group-exchange-sha256

…because OpenSSH server cannot prevent a random (potentially insane)
ssh client from picking a small group (at least not without removing
them from /etc/ssh/moduli, if the distribution is shipping an older
OpenSSH that still has them).

Or have I misunderstood?
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: SHA-1 practical recommendations? [ In reply to ]
On Thu, 11 Mar 2021, James Ralston wrote:

> > If /etc/moduli is missing then dh_new_group_fallback() will use
> > either a 2k or 4k group.
>
> Who is determining this, though? The client or the server?
>
> This exchange:
>
> debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
> debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32
> debug3: send packet: type 34
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
> debug3: receive packet: type 31
> debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
> debug2: bits set: 4092/8192
> debug3: send packet: type 32
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug3: receive packet: type 33
> debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
>
> …suggests that the client tells the server its minimum, desired, and
> maximum group size, and the server picks a group accordingly.

That is accurate.

> But what happens if a random ssh client (not OpenSSH) sends this?
>
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<1024) sent
>
> Will OpenSSH server honor this and pick a 1024-bit group?

If there are any in the moduli file, yes. We do not ship 1024 bit groups
in the moduli file and haven't for some time.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev