Re: telnet vs ssh [WAS: Re: Dropping telnetd and rsh* for security reasons?]
On Fri, 23 May 2003, Karsten M. Self wrote:
> on Fri, May 16, 2003 at 10:56:26AM -0400, Mark Roach (mrroach@okmaybe.com) wrote:
[...]
> > If people would just start implementing ipsec/dnssec on a broader scale,
> > these interim technologies like ssh and ssl could just hurry up and die
> > off already...
> Because that's only part of the problem.
>
> ssh: *authenticated*, *encrypted* remote access.
>
> Telnet and FreeSWAN / ipsec essentially offer one side of the coin each:
> telnet provides authentication (and with one-time passwords, reasonable
> auth at that), but no security. FreeSWAN provides security but no
> authentication. You need both pieces. It makes some sense to drop
> these in at the application layer, tunelling over the app as needed.
>
> Too: nested ipsec within ipsec layers (and if you don't think that's
> going to happen, you haven't seen today's enterprise nested firewall
> nightmare) introduces inefficiencies and latencies into communications.
>
> For the times you simply need to pipe bits from one system to another,
> there's still netcat.
All very true, and I think illustrative of the fact that there are
multiple problems being solved in different ways.
My submission of a credit card number to Amazon must be secure.
"secure" in this context means that me as the end user reasonably
believes that potential third parties cannot see data sent. I'm not
authenticating myself to Amazon via crypto; they are using the data
being transmitted to make a reasonable assumtion about who I am.
This implies a somewhat-reasonably-trusted-path between my keyboard and
thier business logic. HTTPS is a somewhat-reasonably-trusted-path.
This is very different from the problem set ssh attempts to cover.
Ssh attempts to (and does a pretty good job of) both secure against wire
sniffing and authenticate against a shared secret (in the loose sense of
that phrase).
IPsec and similar are blanket methods to secure a data path, regardless
of the content.
That I might tunnel https over an ssh-forwarded connection running over
IPsec doesn't matter; there are different application domains that all
require working in a lowest-common-denominator environment. Solving the
same problem different ways may be inefficient, but tends to be at least
reasonable best common practice.
In other words, attempting to roll all 'security' up into one or a few
methods is to misunderstand what the word 'security' means. It misses
not only the difference between authentication and authorization, but
also fails to provide a method to distinguish various requirements for
authentication or authorization. I, personally, have different notions
of what is required for access to my laptop and what is required for
access to my bank account.
-j
--
Jamie Lawrence jal@jal.org
"Mathematics is the only science where one never knows what one is talking
about nor whether what is said is true."
- Russell
Reply to: