[ On Thursday, November 16, 2000 at 12:42:32 (-0800), Carson Gaspar wrote: ]
> Subject: Re: ssh tunnelling over ssh ?
>
> Nope. No additional security. Either the client has the private host key,
> and is authentic, or doesn't, and is not. Its source port is completely
> irrelevant. The only edge case prevented by requiring a "priviledged"
> source port is:
Sorry, no, that's not the only case by far. In the common way SSH is
use the other, and far more important, case is when the initial
connection is made. If a rogue server process could open and listen on
the default port (say there was no sshd running, or there was some bug
that could trigger the crash of the real one) then it could hand hout a
bogus host key on the *initial* handshake. An unsuspecting user could
connect to a server for the first time and be tricked into accepting a
bogus key.
Now this won't go far if the remote process isn't running as the
superuser unless its designer is very careful to make sure the client is
put into a fake environment that gives every impression of being the
real thing (i.e. the "reverse" of a honeypot-like system) -- at least
long enough for the perpetrator to make some gain from his or her
effort. The worst case would be when an administator logs in and then
immediately does an 'su', thus executing a trojan 'su' which would
possibly fool the admin long enough for the perpetrator to do real
damage. In theory this kind of attack is a very real possibility,
especially with the increasing number of remotely (and I mean half-way
around the world remote!) administered boxes out there. Just what are
you to do as you realise that seconds ago you typed the root password to
a trojan on a box that contains secret data that might be worth real
money to anyone contemplating industrial espionage, and just as you
realize it your connection appears to go dead.
(Not to mention the possibilities of reverse takeovers, such as the one
just reported on BUGTRAQ in where in some versions of OpenSSH the remote
ssh server can force the ssh client to enable agent and X11 forwarding.)
> SSH should, in my not-so-humble opinion:
>
> - Pass handles in-band identifying the client and the server. Currently, it
> uses the IP addresses present in the packet header for this. This is a
> layering violation, and causes SSH to break (at least for some auth types)
> when NAT is present. I recommend that said handles be the FQDN of the host
> by default, but this shouldn't be a hard requirement.
>
> - Use the above handles and the keying material to determine the
> authenticity of the machines in question. Nothing else.
>
> - Optionally (as in a user can turn it off) warn if the handle does not
> match the IP address. This may use DNS data, which is usually untrustworthy
> (unless DNSSEC is deployed). And the discrepancy may be legitimate (if NAT,
> application proxies, or what-have-you are in use). Which is why it should
> be optional. And default to "off".
Yes, I think, these changes would be a very good improvement.
However I would STRONGLY suggest that the default of the DNS matching
check should be 'on' and require the client user to explicitly and
interactively disable it with each connection where it fails, and to
hard-fail the connection if the remote host key also appears to have
changed. If you build a web of trust that involves names, addresses,
*and* keys then the likelyhood of detecting an attack is much higher.
This will not be a problem with NATs in the most common case where the
client may have a random address behind the firewall and the remote
servers are using fixed name/address mappings unless the server is
configured to require a pre-configured known-host public key for each
client. Sites that get this paranoid and which have to deal with
clients which have random IP addresses or addresses which never match
their hostnames can change the setting of the name/address consistency
check. The default however should always be to be as secure as
reasonable and at least in my experience the name/address consistency
check would be more than reasonable since TCP Wrappers and various
prominent FTP servers have already paved the way to making people aware
of the importance of DNS consistency.
BTW, DNS data is as trustworthy as your cache and auth servers -- DNSSEC
doesn't necessarily make it more trustworthgy, it just lets the admins
update it in new and exciting ways without making it *less* trustworthy.
Of course if you're querying a nameserver half way around the world then
it might be helpful to do those queries with DNSSEC, though the
increased amount of trust you can place in the responses isn't really
all that much higher, unless you can trust the remote server itself
implicitly in which case it makes the request and response transit
itself safer.
You still need secure out-of-band key management if you're going to put
any real amount of trust in a remote system where threats are real and
successful compromises are costly.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
