Re: Speeding up SCP for high speed LAN use?

[Marcus Watts <mdw_(_at_)_umich_(_dot_)_edu>]

"Mike Neuman" <mcn_(_at_)_EnGarde_(_dot_)_com> sent:
> > Balony.  You're way off.  To provide just one point... have you ever
> > heard of tcp hijacking?
> 
>   As one of the the two guys who invented TCP hijacking back in '94 (and
> spent nearly a year trying to convince people it really existed and really
> WAS a threat to no avail), it's nice at least SOMEONE remembers it... :-)
> 
>   The first reaction to our announcement was Secure Computing telling
> everyone that's why they should buy SecureID cards... Uhh... Yeah...

I figured out TCP hijacking was possible in the mid 80's.  I don't
remember bothering to tell anyone about it, it seemed so, duh,
obvious.

In a previous bit of this exchange, you indicated that your concern was
uploading files to an anonymous ftp repository.  There have in fact
been a number of recent attacks trying to compromise the contents of
such sites, so Theo's concern is not quite as far fetched as you might
think (although it takes a fairly sophisticated vandal with very good
network access and tools to carry off a tcp hijacking attack.  Most
vandals find easier ways to attack sites.)

For your anonymous ftp repository, clearly, you aren't interested in
privacy, and you probably only semi-care about reliability.  In that
sense, yes, what scp does in encrypting the channel just slows you
down.  What you *do* care about is knowing whether you actually got
your contents across.  For that, you do need authentication, and you
need to encrypt *something*.  But you don't need to encrypt the whole
file to do that - you just need to encrypt some sort of checksum on the
file contents (probably you should also have some sort of check on the
length of things to avoid some sort of tcp insertion attack.)

I don't think you can do this with "scp" though - what scp does is it
provides a secure communications channel, and any content that gets
exchanged is layered on top, invisibly to the communcations channel.
But you are asking that your actual communications channel be insecure,
and you want your security at a higher "contents" level, so that you
know if you got your file across ok.  You could do something very like
this using "pgp -s" (as opposed to -e -es or -c).  In theory, the ssh
suite could provide a means to provide a connection that does not
actually encrypt data, but does encrypt and secure the checksums on
that data.  I don't know that there is actually any mechanism in the
protocol to support such a channel, and certainly this would be a
relatively "dangerous" mode to use ssh. For one thing, it may be
difficult to avoid a "down-negotiate" attack on the initial protocol
setup, before ciphers are agreed upon.  For another, it's not obvious
how good humans would be at recognizing that just because they can't
*see* their password being echoed, doesn't mean it's not going through
the dangerous mode ssh in the clear.

For what it's worth, most versions of "AFS" actually does do "secure
but not private" checksum only encryption by default on file contents.
AFS also works using udp instead of tcp, so that means a tcp hijacking
attack can't break your connection; as opposed to ssh, where pretty
much any encryption error means you should just close down your
connection and start over.
	(This doesn't mean as much as you might think in practice,
	since there's also an unauthenticated rx packet you can send to
	tell the other end that the connection is hosed.  Normally, a
	server that doesn't like your ticket, perhaps because it's
	expired, would send this.)

					-Marcus Watts