Re: Client-side SSH_MSG_EXT_INFO: Use it or lose it principle!

About this:

> TLS dealt with this to some extent by adding a mechanism
> bacronym'd as GREASE for sending random information in
> extensions to detect implementations that broke on them,
> perhaps something similar could be done for SSH.

The challenge with this is that some widely used implementation -
*cough*OpenSSH*cough* - would need to exercise all functions of the
protocol that are legal, but not necessarily in widespread use. If they
want to prevent rusting at the joints, OpenSSH would have to do so for most
features, including those they do not CURRENTLY find useful.

For example, if a common problem is that clients fail to correctly handle
global requests if they receive them while waiting for channel open
confirmation - this is a bug that both OpenSSH and PuTTY had, at some point
long ago - then the way to exercise that would be to include a trivial
global request, in say 10% of cases, before a channel open confirmation.

I would welcome that, personally, and hence that's why I originally
included Damien in this thread. :)

denis


On Mon, Apr 27, 2020 at 12:37 AM Peter Gutmann <pgut001-kVWAYfnMFF2W8ldZTk/[email protected]>
wrote:

> denis bider <[email protected]> writes:
>
> >it has come to my attention that at least one SSH server implementation
> (a)
> >advertises support for SSH_MSG_EXT_INFO as defined in RFC 8308, and (b)
> >disconnects on actual receipt of an EXT_INFO message from the client.
>
> Not wanting to do a public name-and-shame on this, but could you share the
> ID
> string needed to fingerprint this server?  Looks like a lot of
> implementations
> will need to be able to deal with this...
>
> >This happens when we define a general mechanism, but then the most widely
> >used implementations only use certain aspects of it.
>
> That's a more specific version of "an implementation is fully SSH
> standards-
> compliant when it can connect to OpenSSH (client) or Putty can connect to
> it
> (server)".  Those two are the universal benchmark for SSH implementations,
> for
> better or for worse.  TLS dealt with this to some extent by adding a
> mechanism
> bacronym'd as GREASE for sending random information in extensions to detect
> implementations that broke on them, perhaps something similar could be done
> for SSH.
>
> Peer.

_______________________________________________
Curdle mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/curdle