[linux-elitists] telnet weenie frenzy!
Tue Feb 27 12:30:12 PST 2001
begin Bulent Murtezaoglu quotation:
> If we can assume the above, I am asserting it is not incredibly harder
> for the same adversary to modify intermediate routers' behaviour even
And? Ah, I see we get into that, below.
> No I have not. I am basing all this on the behaviour I am seeing on
> my boxes, they resolve non-us.debian.org, they get a list of available
> packages from there, they fetch (in the clear using http or ftp) the
> packages I want and/or updates for the ones I already use, and they
> install them. I do not see any attempt at authenticating the other
> end, I do see some checksum checking but that's done against checksums
> acquired through the same source. I admit that I do not know about
> the measures you allude to. This is partly because I always assumed
> that something as simple as a transparent http proxy that replaces
> packages (*) would be enough to compromize the distribution and I could
> not see any measures in addition to the existing framework that would
> work against that.
Yes, that might do it, to fool around with a local network downstream --
but of course you would have to implement this on a router capable of
such functions. This is one of the reasons that hardware-based routers
are popular: They have a deliberately limited range of functionality.
And then there is, as you say, the ever-popular option of poisoning or
subverting DNS servers. I don't know about you, but this is why I run
my _own_ DNS boxen, and administer them in a fairly paranoid way.
Yes, not everyone does: Yes, security is a hard problem.
> Having already badmouthed the measures w/o knowing what they are,
> could I now impose on you to point me to some write-up about them?
<sigh> I wish I could. In the case of the Debian Project, there is
some key documentation that hasn't been written yet -- and in fact I've
considered bearing down and writing some of it. But not today. You
might ask on the debian-security mailing list. Please see:
One of the missing pieces _has_ been, to be sure, a well-architected
mechanism for distributing and authenticating the keys required for
_meaningful_ verification of packages. (RPM-style signing of packages
is supported, but not meaningful without those other pieces.) This, in
part, was on hold until the expiration of the USA patent on RSA. Now,
that obstacle is gone, but doing it right remains a hard problem.
> ...if you really need protection against compromises in the routers in
> your path, you also ought to be thinking about all the traffic that
> passes through those.
Well, of course one does. Thus, the drive towards DNSSEC, SSL/TLS
(including HTTPS), and SSH. Not to mention the ongoing focus on solving
the (essentially) unsolved certificate / key-distribution & revocation
problem. (See Bruce Scneier's _Secrets and Lies_, on this point.)
> "Quit using telnet" is only part of the solution....
> -- given a dedicated and knowledgeable adversary with roughly the same
> access, the telnet risk pales in comparison to, say, apt-get. Agreed?
No. But you may wish to inquire on email@example.com,
because we're probably not going to get anywhere in the current
discussion -- and it's probably not the right place and time, in the
first place. (I have to admit that I don't have the time to spare, for
one thing. Apologies if that seems brusque: It's not so intended.)
Cheers, We write precisely We say exactly
Rick Moen Since such is our habit in How to do a thing or how
firstname.lastname@example.org Talking to machines; Every detail works.
Excerpt from Prof. Touretzky's decss-haiku.txt @ http://www.cs.cmu.edu/~dst/
More information about the linux-elitists