[818] in bugtraq
Re: Would an encrypted tunnel solve the SeqNo guessing attack?
daemon@ATHENA.MIT.EDU (Paul Robinson)
Fri Jan 27 14:11:35 1995
Date: Fri, 27 Jan 1995 12:04:08 -0500 (EST)
From: Paul Robinson <tdarcos@access.digex.net>
To: Bennett Todd <bet@std.sbi.com>
Cc: Bugtraq mailing list <bugtraq@fc.net>
In-Reply-To: <9501262104.AA21300@std.sbi.com>
On Thu, 26 Jan 1995, Bennett Todd wrote:
> I'm not keen on the idea of people grabbing my telnet session away from me
> and making free with it. I'm resigned to the notion that they can steal
> it; I'd like to make it useless to them once they've got it.
>
> Suppose I took term (a multiplexing, compressing, error-correcting serial
> tunnel program) and added encryption, and rigged that to be my login shell.
> I'd log in to the computer, and after my S/Key prompt it'd fire up an
> encrypted term. I don't see any way some could burgle in through that.
>
> Have I missed something fundamental here? Or would this work?
If he has to have something on his end to connect to that program that
would require a serial number, sequence number or something else that
would be difficult to guess, probably.
But then again, it requires some specialized service capabilities from
the caller's end. And if it's a pain to use, or denies people some means
of using their favorite terminal program, it may either not get used or
not get used very much.
For example, I use Telemate, which I have used for more than 3 years
because of its powerful multiprocessing capabilty, including built in
text editor, file viewer, DOS shell and internal Zmodem. Has all of the
top features including cut and paste in all venues (cut and paste to and
from the editor and screen, cut from the file vewer to the screen or the
editor), a programmable script language, a script learn facility,
emulation for VT100, ANSI and the emulation code can be customized for
other terminal types, ability to program allmost all ALT and Function key
combinations for macro capability, and other features, plus the ability
to multiprogram, where I can Zmodem download on the screen, then read a
file of downloaded messages in another window while the program continues
the download (or upload). This is all done from MS DOS, *not* using any
special multitasking programs.
I probably tried in excess of 20 different terminal programs before I
found this one, and while the program gives 30 days to decide to register
it, I didn't even wait two weeks before sending in a check: the program
was too good *not* to pay for it.
Point being that I have become accustomed to this program, and its
excellent features increase my online productivity by a significant
amount. When I use another terminal program, it *hurts* because I lose a
significant functionality which I have in Telemate.
Telemate will, however, talk through a fossil driver or INT 14 on the PC,
and thus can be used through a "software shim" for unusual hardware *or
unusual communications conditions*.
This is probably true of other people using programs on other machines
and need this sort of capability.
I therefore propose that those of us who are interested consider creating
a standard for a traffic encryption or traffic management protocol (TMP) so
that all I have to do, if I'm going to log into a TMP secured host, is
load a TSR ahead of my terminal program, and the TSR only reacts if it
receives a "begin TMP secured protocol" sequence. The terminal program
I'm using and the recipient software at the other end need no
modification, and they just talk to the "software shims" at their end,
while the "shims" send encrypted traffic between one another.
If the standard is published, not black box and easily implementable, we
eliminate the "security through obscurity" nonexistent protections, and
thus create a standard so anyone can perform encrypted connections and
not have to worry about the innards; just fire up the software and let it
take care of the underlying protocol.
Anyone interested in working on this, write me back.
--
Ask me about Listmgr - the first PC-Based mailing list manager for E-Mail.
Reports on Security Problems: To Subscribe write PROBLEMS-REQUEST@TDR.COM
Paul Robinson - paul@tdr.com / tdarcos@MCIMail.com / tdarcos@access.digex.net
Voted "Largest Polluter of the (IETF) list" by Randy Bush <randy@psg.com>
