[ On Saturday, March 9, 2002 at 19:17:08 (-0500), Thor Lancelot Simon wrote: ]
> Subject: Re: FreSSH
>
> On Sat, Mar 09, 2002 at 07:05:23PM -0500, Greg A. Woods wrote:
> > [ On Saturday, March 9, 2002 at 17:53:31 (-0500), Charles Shannon Hendrix wrote: ]
> > > Subject: Re: FreSSH
> > >
> > > I don't care if my vi edits and the guts of my tar files are visible
> > > on the net.
> > 
> > You don't seem to understand what "hijack your connection" means in
> > practice.
> 
> You don't seem to understand that message authentication and message
> encryption aren't the same thing.

Oh, I very much do understand the difference, and the implications.

In fact my argument was leading up to these specific issues.

I don't remember exactly how careful I was to always use the phrase
"strong cryptography" instead of "encryption", (and I can't be bothered
to review my posts), but that was my intent.  You'll note that a "strong
message authentication code" is a form of "strong crtypography".

However a great many people don't seem to understand that TCP/IP,
without IPsec, has no secure authentication for individual packets.
Strong Message Authentication Codes and perhaps encryption are left to
the application.  Even worse is the fact that if your threat scenario
assumes that your packets can be sniffed by an attacker, then you must
also assume that the attacker may be able to mediate all packets sent
over your connection and in theory even go so far as to show you what
you expect to see even when you run tcpdump to view your packets as they
arrive at the other end (while in the mean time actually using your
session for whatever nefarious purposes ).

Yes SSHv2 can do message authentication without encrypting the data.  Do
"you" want it to not encrypt your data though?  Maybe for a very few
purposes where the "cost" of encryption might get in the way and the
data is already public, but definitely not by default.  You sure as heck
don't want to disable encryption and then momentarily forget you've done
so and accidentally type an important piece of non-public information,
such as a password, across an unencrypted connection!  I'd personally
rather use a faster encryption algorithm for bulk non-anonymous public
data transfers than to just turn it off, partly for the same reasons I'd
still use SSH even if the packets I sent to a remote host were also
re-encrypted with IPsec.  I don't trust myself to send only public data
through an un-encrypted channel, and I don't know that I trust a strong
MAC alone to protect my session from person-in-the-middle attacks.

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>