<comments below>
On Fri, 26 Jul 2002, Bela Lubkin wrote:
> Burton M. Strauss III wrote:
>
> > You know, that's only partially a solution. For those of us who haven't
> > chosen to PAY for the upgrade to 3.4, we're left out in the cold. Quoting
> > from VanDyke's web page:
> >
> > "All users may evaluate SecureCRT 3.4 for 30 days free of charge. Registered
> > users who purchased licenses before July 1, 2000 should consult the Upgrade
> > Eligibility page to learn about licensing the 3.4 upgrade."
> >
> > and
> >
> > "SecureCRT Upgrade
> >
> > Registered users who purchased licenses before July 1, 2001 may choose to
> > purchase SecureCRT upgrades starting at $39.95 for a single copy.
> >
> > <snip />
> >
> > SecureCRT users who purchased licenses between January 1 and July 1, 2000
> > are eligible to download SecureCRT 3.3.3 and upgrade without charge.
> > SecureCRT users who purchased licenses before January 1, 2000 are eligible
> > to download SecureCRT 3.2.1 and upgrade without charge."
> >
> >
> > I'm not unsympathetic to the need to have a licensing revenue stream, but
> > let's remember that this leaves (dozens? hundreds? thousands? Just me) of
> > your customers unprotected.
>
> One of the README files on their site (I read it earlier today and
> didn't note the URL) says that a patched 3.2.1 version will be made
> available shortly. They are not leaving you out in the cold. You just
> need to wait a couple of days before resuming your practice of ssh'ing
> in to untrusted sites.
>
> (BTW, if sshd on a site might be a corrupted, malicious trojan which
> injects code into your local ssh client -- might it not also be a
> corrupted, malicious trojan which records encrypted password
> information, passes on a decrypted stream of everything you type in a
> session, or who knows what else? If you do not trust the sshd to which
> you are connecting, I'm not sure it makes very much difference whether
> the client has code-injection portholes or not...)
>
> >Bela<
Of course it matters if the client has code-injection 'portholes' as you
call them. Someone may be using nasty tricks through ARP, DNS, or even
manipulating routing tables, such that you are not actually connecting to
a host you trust. This is why ssh implements host keys, so you can verify
the authenticicy of the remote host. However, in the case described
above, with SecureCRT, your machine would already be compromised before
host key verification took place.
-Russell Harding
This archive was generated by hypermail 2b30 : Sun Jul 28 2002 - 00:24:01 PDT