Re: Identifying a buggy SFTP server found at an archaeological dig

Ron Frederick <[email protected]> Wed, 8 May 2024 21:03:05 -0700
Newsgroups gmane.ietf.secsh
Message-ID <[email protected]>

--Apple-Mail=_4ED5DE2F-CBB4-43B7-86FA-BD9D427182B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On May 8, 2024, at 1:18=E2=80=AFAM, Peter Gutmann =
<[email protected]> wrote:
> Ron Frederick <[email protected]> writes:
>=20
>> A quick search for that identification string with Google seems to =
point at a
>> =E2=80=9CChilkat sFTP=E2=80=9D server
>=20
> Yeah, I'd seen that too but saw other info that it used "SSH-2.0-
> Chilkat_<version>", and I'm nervous about adding a bugfix for a =
particular
> broken server that may end up misidentifying non-broken servers, =
either ones
> that use the same generic string or ones that fixed it at some point =
but since
> the string doesn't include a version you can't tell who's running the =
fixed
> version.  =46rom this page:
>=20
> https://www.chilkatsoft.com/refdoc/cssftpref.html
>=20
> it looks like they disabled stuff like HMAC-MD5, RIPEMD-160, and =
similar only
> in the very latest version (April 2024), so perhaps "SSH-2.0-FTP =
Server ready"
> =3D broken, "SSH-2.0-Chilkat_<version>" =3D non-broken?


The version in the last link I sent was 9.5.0.43, which is actually =
older than the Chilkat release notes seem to cover (oldest is 9.5.0.75 =
from 2018), but that seems consistent with 9.5.0.43 being from 2014. If =
you could find a way to download that version (perhaps from one of the =
Internet archives?), you might be able to confirm what server identifier =
it defaults to. Since this appears to be a commercial product, though, =
that may be easier said than done. You=E2=80=99re probably better off =
reaching out to the company to see when they added support for the =
current SSH_MSG_KEY_DH_GEX_REQUEST (34) rather than =
SSH_MSG_KEY_DH_GEX_REQUEST_OLD (30).

Alternately, you could try and work around this by having your client =
not advertise any of the group-exchange kex algorithms (anything =
starting with "diffie-hellman-group-exchange-=E2=80=9C).
--=20
Ron Frederick
[email protected]




--Apple-Mail=_4ED5DE2F-CBB4-43B7-86FA-BD9D427182B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;">On May 8, =
2024, at 1:18=E2=80=AFAM, Peter Gutmann =
&lt;[email protected]&gt; wrote:<div><blockquote =
type=3D"cite"><div><div>Ron Frederick &lt;[email protected]&gt; =
writes:<br><br><blockquote type=3D"cite">A quick search for that =
identification string with Google seems to point at a<br>=E2=80=9CChilkat =
sFTP=E2=80=9D server<br></blockquote><br>Yeah, I'd seen that too but saw =
other info that it used "SSH-2.0-<br>Chilkat_&lt;version&gt;", and I'm =
nervous about adding a bugfix for a particular<br>broken server that may =
end up misidentifying non-broken servers, either ones<br>that use the =
same generic string or ones that fixed it at some point but since<br>the =
string doesn't include a version you can't tell who's running the =
fixed<br>version. &nbsp;=46rom this =
page:<br><br>https://www.chilkatsoft.com/refdoc/cssftpref.html<br><br>it =
looks like they disabled stuff like HMAC-MD5, RIPEMD-160, and similar =
only<br>in the very latest version (April 2024), so perhaps "SSH-2.0-FTP =
Server ready"<br>=3D broken, "SSH-2.0-Chilkat_&lt;version&gt;" =3D =
non-broken?<br></div></div></blockquote></div><div><br></div>The version =
in the last link I sent was 9.5.0.43, which is actually older than the =
Chilkat release notes seem to cover (oldest is 9.5.0.75 from 2018), but =
that seems consistent with 9.5.0.43 being from 2014. If you could find a =
way to download that version (perhaps from one of the Internet =
archives?), you might be able to confirm what server identifier it =
defaults to. Since this appears to be a commercial product, though, that =
may be easier said than done. You=E2=80=99re probably better off =
reaching out to the company to see when they added support for the =
current SSH_MSG_KEY_DH_GEX_REQUEST (34) rather than =
SSH_MSG_KEY_DH_GEX_REQUEST_OLD (30).<div><br></div><div>Alternately, you =
could try and work around this by having your client not advertise any =
of the group-exchange kex algorithms (anything starting with =
"diffie-hellman-group-exchange-=E2=80=9C).<br><div><div>
--&nbsp;<br>Ron Frederick<br>[email protected]<br><br><br>

</div>
<br></div></div></body></html>=

--Apple-Mail=_4ED5DE2F-CBB4-43B7-86FA-BD9D427182B9--