--On Wednesday, November 15, 2000 11:27 PM -0500 "Greg A. Woods"
<[EMAIL PROTECTED]> wrote:
> [ On Wednesday, November 15, 2000 at 15:54:07 (-0800), Carson Gaspar
> wrote: ]
>> Subject: Re: ssh tunnelling over ssh ?
>>
>> Requiring a
>> priveledged port on the server adds _no_ security and is a bad idea. I
>> added an option to turn that silly requirement off.
>
> Requiring that the server listen on a privileged port helps ensure, at
I was unclear - this is not what I meant. See below.
> In some scenarios where the local network wire is also trusted one can
> even use the fact that the client connected from a trusted port to know
> that the information passed by the client is in effect authenticated.
> This also applies to SSH since it is this fact which corroberates the
> authenticity of the client's host key by implying that it was done by a
> privileged process capable of reading the protected host key.
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:
- The server only allows connections from "trusted" IP addresses
- The private host key on a "trusted" box has been compromised
- The user does not have root on said box (the key was compromised off of
backup tapes?)
- The user cannot spoof a "trusted" IP address
- The user cannot examine traffic between the trusted machine and the server
I have _never_ seen this combination in the wild. A _really_ annoying
requirement that only protects against a key compromise in non-extant
circumstances is a bad idea. Didn't we learn our lesson about trusting IP
addresses and source ports with the abomination of rlogin/rsh/etc.?
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".
--
Carson Gaspar - [EMAIL PROTECTED]
Queen trapped in a butch body
